Original patch by Andrey Guskov!
http://reviews.llvm.org/D5651

llvm-svn: 219327

llvm-svn: 219324

This seems to cause a miscompile when building clang, which causes a
bootstrapped clang to fail or crash in several of its tests.

See:
  http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-RA/builds/1184
  http://bb.pgr.jp/builders/clang-3stage-x86_64-linux/builds/7813

This reverts commit r219282.

llvm-svn: 219317

Added CMP_MASK_CC intrinsic type.
Added tests for intrinsics.

Patch by Sergey Lisitsyn <sergey.lisitsyn@intel.com>

llvm-svn: 219316

There are two methods in SectionRef that can fail:

* getName: The index into the string table can be invalid.
* getContents: The section might point to invalid contents.

Every other method will always succeed and returning and std::error_code just
complicates the code. For example, a section can have an invalid alignment,
but if we are able to get to the section structure at all and create a
SectionRef, we will always be able to read that invalid alignment.

llvm-svn: 219314

llvm-svn: 219312

Added new argrument for AVX512_masking: InstrItinClass and bit isCommutable.
No functional change.

llvm-svn: 219310

Patch by Charlie Turner.

llvm-svn: 219301

This must be enforced for all v6M cores, not just the cortex-m0,
irregardless of the user-specified alignment.

Patch by Charlie Turner.

llvm-svn: 219300

This switch can be reduced to a simpler if/else statement.

Patch by Charlie Turner.

llvm-svn: 219299

SelectionDAG in SelectionDAGBuilder rather than going through
the TargetMachine for lookup.

llvm-svn: 219292

MachineFunction rather than a lookup on the TargetMachine
to avoid unnecessary lookups.

llvm-svn: 219291

We won't link in pthreads if we weren't built with LLVM_ENABLE_THREADS
which means we won't get access to pthread_sigmask.  Use sigprocmask
instead.

llvm-svn: 219288

cached variables and a single call in the constructor.

llvm-svn: 219287

Differential Revision: http://reviews.llvm.org/D5649
 

llvm-svn: 219286

TargetMachine again.

llvm-svn: 219285

calls to getTargetLowering() with the cached variable.

llvm-svn: 219284

A linkonce_odr member of a COMDAT shouldn't be dropped if we need to
keep the entire COMDAT group.

This fixes PR21191.

llvm-svn: 219283

The icmp-select-icmp optimization targets select-icmp.eq
only. This is now ensured by testing the branch predicate
explictly. This commit also includes the test case for pr21199.

llvm-svn: 219282

COFF normally doesn't allow us to describe the alignment of COMMON
symbols.

It turns out that most linkers use the symbol size as a hint as to how
aligned the symbol should be.

However the BFD folks have added a .drectve command, which we
now support as of r219229, that allows us to specify the alignment
precisely.  With this in mind, stop rounding sizes up.

llvm-svn: 219281

DWARF in COFF utilizes several relocations.  Implement support for them
in RelocVisitor to support llvm-dwarfdump.

llvm-svn: 219280

Phabricator Revision: http://reviews.llvm.org/D5589
Patch by Balaram Makam <bmakam@codeaurora.org>!!

llvm-svn: 219276

propagate. Also use the TargetSubtargetInfo and the MachineFunction
and move TargetRegisterInfo query closer to uses.

llvm-svn: 219273

thing we do inside selection dag. This code needs to be
migrated to queries on the function rather than global
data, but this organizes things before we start grabbing
the subtarget.

llvm-svn: 219271

inside init rather than have it passed in as an argument.

llvm-svn: 219270

This seems to have caused PR21199.

llvm-svn: 219264

during init rather than construction time.

llvm-svn: 219262

Keep the actual section contents and the relocation map together.

llvm-svn: 219261

mach-o supports "fat" files which are a header/table-of-contents followed by a
concatenation of mach-o files built for different architectures. Currently, 
MemoryBuffer has no easy way to map a subrange (slice) of a file which lld
will need to select a mach-o slice of a fat file. The new function provides 
an easy way to map a slice of a file into a MemoryBuffer. Test case included.

llvm-svn: 219260

llvm-svn: 219259

Summary:
Fix pr21099

The pseudocode of what we were doing (spread through two functions) was:
if (operand.doesNotFitIn32Bits())
  Opc.initializeWithFoo();
if (operand < 0)
  operand = -operand;
if (operand.doesFitIn8Bits())
  Opc.initializeWithBar();
else if (operand.doesFitIn32Bits())
  Opc.initializeWithBlah();
doStuff(Opc);

So for operand == INT32_MIN, Opc was never initialized because the operand changes
from fitting in 32 bits to not fitting, causing the various bugs/error messages
noted by pr21099.

This patch adds an extra test at the beginning for this case, and an
llvm_unreachable to have better error message if the operand ends up
not fitting in 32-bits at the end.

Test Plan: new test + make check

Reviewers: jfb

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D5655

llvm-svn: 219257

llvm-svn: 219256

llvm-svn: 219255

llvm-svn: 219254

llvm-svn: 219253

It would be more convenient to pass DWARFSection into DWARFUnitSection
constructor, instead of passing its components (Data and RelocAddrMap)
as a separate arguments.

llvm-svn: 219252

DebugInfo+DFSan: Ensure that debug info references to llvm::Functions remain pointing to the underlying function when wrappers are created

This is somewhat the inverse of how similar bugs in DAE and ArgPromo
manifested and were addressed. In those passes, individual call sites
were visited explicitly, and then the old function was deleted. This
left the debug info with a null llvm::Function* that needed to be
updated to point to the new function.

In the case of DFSan, it RAUWs the old function with the wrapper, which
includes debug info. So now the debug info refers to the wrapper, which
doesn't actually have any instructions with debug info in it, so it is
ignored entirely - resulting in a DW_TAG_subprogram with no high/low pc,
etc. Instead, fix up the debug info to refer to the original function
after the RAUW messed it up.

Reviewed/discussed with Peter Collingbourne on the llvm-dev mailing
list.

llvm-svn: 219249

llvm-svn: 219242

`LoopUnrollPass` says that it preserves `LoopInfo` -- make it so.  In
particular, tell `LoopInfo` about copies of inner loops when unrolling
the outer loop.

Conservatively, also tell `ScalarEvolution` to forget about the original
versions of these loops, since their inputs may have changed.

Fixes PR20987.

llvm-svn: 219241

A follow-up commit will add use to a tight loop.  We might as well just
find it once anyway.

llvm-svn: 219239