and update test cases accordingly.

This doesn't affect the output dumped using llvm-dwarfdump, but
readelf does now dump the debug_loc section.

llvm-svn: 194898

DwarfCompileUnit: Add type safety to CompileUnit::getNode by returning DICompileUnit instead of a raw MDNode*.

llvm-svn: 194895

DwarfCompileUnit: Add type safety by using DICompileUnit rather than raw MDNode* for the CU metadata node

llvm-svn: 194893

llvm-svn: 194892

Implemented aarch64 Neon scalar vfma_lane intrinsics
Implemented aarch64 Neon scalar vfms_lane intrinsics

Implemented legacy vmul_n_f64, vmul_lane_f64, vmul_laneq_f64
intrinsics (v1f64 parameter type) using Neon scalar instructions.

Implemented legacy vfma_lane_f64, vfms_lane_f64,
vfma_laneq_f64, vfms_laneq_f64 intrinsics (v1f64 parameter type)
using Neon scalar instructions.

llvm-svn: 194888

llvm-svn: 194883

llvm-svn: 194882

until we know that folding will be successful.

No functional change.

llvm-svn: 194880

llvm-svn: 194879

When we vectorize a scalar access with no alignment specified, we have to set
the target's abi alignment of the scalar access on the vectorized access.
Using the same alignment of zero would be wrong because most targets will have a
bigger abi alignment for vector types.

This probably fixes PR17878.

llvm-svn: 194876

llvm-svn: 194875

This is the first of a few similar patches. We'll see how far it
goes/makes sense.

llvm-svn: 194871

This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.

Differential Revision: http://llvm-reviews.chandlerc.com/D2068

Reviewed by Andy

llvm-svn: 194865

The error reported the number of explicit operands,
but that isn't what is checked. In my case, this
resulted in the confusing errors

"Too few operands." followed shortly by
"8 operands expected, but 8 given."

llvm-svn: 194862

Patch by Keno Fischer!

llvm-svn: 194859

llvm-svn: 194858

AaronBallman. Thanks for the excellent review.

llvm-svn: 194857

pulling them under 80-columns. No functionality changed.

llvm-svn: 194856

rather than the vector equivalent.

llvm-svn: 194853

Summary: Make identify_magic to recognize COFF import file.

Reviewers: Bigcheese

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2165

llvm-svn: 194852

llvm-svn: 194848

We used to use std::map<IndicesVector, LoadInst*> for OriginalLoads, and when we
try to promote two arguments, they will both write to OriginalLoads causing
created loads for the two arguments to have the same original load. And the same
tbaa tag and alignment will be put to the created loads for the two arguments.

The fix is to use std::map<std::pair<Argument*, IndicesVector>, LoadInst*>
for OriginalLoads, so each Argument will write to different parts of the map.

PR17906

llvm-svn: 194846

0xffff does not mean that there are 65535 sections in a COFF file but
indicates that it's a COFF import library. This patch fixes SEGV error
when an import library file is passed to llvm-readobj.

llvm-svn: 194844

If getDIE() fails, getOrCreateContextDIE() should also return the CUDie.

llvm-svn: 194843

Stop folding constant adds into GEP when the type size doesn't match.
Otherwise, the adds' operands are effectively being promoted, changing the
conditions of an overflow.  Results are different when:

    sext(a) + sext(b) != sext(a + b)

Problem originally found on x86-64, but also fixed issues with ARM and PPC,
which used similar code.

<rdar://problem/15292280>

Patch by Duncan Exon Smith!

llvm-svn: 194840

This fixes a crash with GNOME settings manager.

llvm-svn: 194836

Patch by James Lyon!

llvm-svn: 194832

Patch by Dale Martin!

llvm-svn: 194831

llvm-svn: 194824

[mips][msa] lowerMSABitClear() should use SelectionDAG::getNOT() instead of using a long-winded equivalent.

Now that getConstant(-1, MVT::v2i64) works correctly on MIPS32 we can use
SelectionDAG::getNOT() to produce the bitmask.

llvm-svn: 194819

llvm-svn: 194818

Summary:
When getConstant() is called for an expanded vector type, it is split into
multiple scalar constants which are then combined using appropriate build_vector
and bitcast operations.

In addition to the usual big/little endian differences, the case where the
element-order of the vector does not have the same endianness as the elements
themselves is also accounted for.  For example, for v4i32 on big-endian MIPS,
the byte-order of the vector is <3210,7654,BA98,FEDC>. For little-endian, it is
<0123,4567,89AB,CDEF>.
Handling this case turns out to be a nop since getConstant() returns a splatted
vector (so reversing the element order doesn't change the value)

This fixes a number of cases in MIPS MSA where calling getConstant() during
operation legalization introduces illegal types (e.g. to legalize v2i64 UNDEF
into a v2i64 BUILD_VECTOR of illegal i64 zeros). It should also handle bigger
differences between illegal and legal types such as legalizing v2i64 into v8i16.

lowerMSASplatImm() in the MIPS backend no longer needs to avoid calling
getConstant() so this function has been updated in the same patch.

For the sake of transparency, the steps I've taken since the review are:
* Added 'virtual' to isVectorEltOrderLittleEndian() as requested. This revealed
  that the MIPS tests were falsely passing because a polymorphic function was
  not actually polymorphic in the reviewed patch.
* Fixed the tests that were now failing. This involved deleting the code to
  handle the MIPS MSA element-order (which was previously doing an byte-order
  swap instead of an element-order swap). This left
  isVectorEltOrderLittleEndian() unused and it was deleted.
* Fixed build failures caused by rebasing beyond r194467-r194472. These build
  failures involved the bset, bneg, and bclr instructions added in these commits
  using lowerMSASplatImm() in a way that was no longer valid after this patch.
  Some of these were fixed by calling SelectionDAG::getConstant() instead,
  others were fixed by a new function getBuildVectorSplat() that provided the
  removed functionality of lowerMSASplatImm() in a more sensible way.

Reviewers: bkramer

Reviewed By: bkramer

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1973

llvm-svn: 194811

Using a special machine node is cleaner than an InlineAsm node, and fixes an assertion failure in InstrEmitter

llvm-svn: 194810

llvm-svn: 194808

llvm-svn: 194800

llvm-svn: 194799

llvm-svn: 194792

I was able to successfully run a bootstrapped LTO build of clang with
r194701, so this change does not seem to be the cause of our failing
buildbots.

llvm-svn: 194789

llvm-svn: 194786

This is to avoid this transformation in some cases:
fold (conv (load x)) -> (load (conv*)x)

On architectures that don't natively support some vector
loads efficiently casting the load to a smaller vector of
larger types and loading is more efficient.

Patch by Micah Villmow.

llvm-svn: 194783