llvm-svn: 204876

paste.

llvm-svn: 204875

instead of rolling an inefficient version of the function. This
changes some order of emission of metadata nodes, fix up those
testcases and make them more flexible to some changes.

llvm-svn: 204874

llvm-svn: 204873

llvm-svn: 204872

llvm-cov tests are sensitive to line number changes, so putting this
at the end will limit churn when we fix the XFAIL.

llvm-svn: 204871

Add the "lldb_complete" .editrc command back in case veteran users of LLDB had .editrc key mappings in their ~/.editrc.

<rdar://problem/16279283>

llvm-svn: 204870

syntax, don't forget to run its initializer.

llvm-svn: 204869

llvm-svn: 204868

Fixed a crasher when using 1 character type names in “type summary”, “type synthetic” and “type filter”.

Also fixed a missing return when making python summary functions on the fly.

<rdar://problem/16265491>

llvm-svn: 204867

Summary:
Tested with a unit test because we don't appear to have any transforms
that use this other than ASan, I think.

Fixes PR17935.

Reviewers: nicholas

CC: llvm-commits

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

llvm-svn: 204866

This is a fix for PR# 19051. I noticed code gen differences due to code motion when running tests with and without the debug info at O2. The problem is in branch folding. A loop wanted to skip the debug info, but actually it didn't do so.

llvm-svn: 204865

llvm-svn: 204864

Functions may in an instrumented binary but not in the original source
when they're inserted by the compiler or the runtime. These functions
aren't meaningful to the user, so teach llvm-cov to skip over them
instead of crashing.

llvm-svn: 204863

when modules are disabled. // rdar://15505492

llvm-svn: 204862

vector list parameter that is using all lanes "{d0[], d2[]}" but can
match and instruction with a ”{d0, d2}" parameter.

I’m finishing up a fix for proper checking of the unsupported
alignments on vld/vst instructions and ran into this.  Thus I don’t
have a test case at this time.  And adding all code that will
demonstrate the bug would obscure the very simple one line fix.
So if you would indulge me on not having a test case at this
time I’ll instead offer up a detailed explanation of what is
going on in this commit message.

This instruction:

	vld2.8  {d0[], d2[]}, [r4:64]

is not legal as the alignment can only be 16 when the size is 8.
Per this documentation:

A8.8.325 VLD2 (single 2-element structure to all lanes)
 <align> The alignment. It can be one of:
16 2-byte alignment, available only if <size> is 8, encoded as a = 1.
32 4-byte alignment, available only if <size> is 16, encoded as a = 1.
64 8-byte alignment, available only if <size> is 32, encoded as a = 1.
omitted Standard alignment, see Unaligned data access on page A3-108.

So when code is added to the llvm integrated assembler to not match
that instruction because of the alignment it then goes on to try to match
other instructions and comes across this:

	vld2.8  {d0, d2}, [r4:64]

and and matches it. This is because of the method
ARMOperand::isVecListDPairSpaced() is missing the check of the Kind.
In this case the Kind is k_VectorListAllLanes . While the name of the method
may suggest that this is OK it really should check that the Kind is
k_VectorList.

As the method ARMOperand::isDoubleSpacedVectorAllLanes() is what was
used to match {d0[], d2[]}  and correctly checks the Kind:

  bool isDoubleSpacedVectorAllLanes() const {
    return Kind == k_VectorListAllLanes && VectorList.isDoubleSpaced;
  }

where the original ARMOperand::isVecListDPairSpaced() does not check
the Kind:

  bool isVecListDPairSpaced() const {
    if (isSingleSpacedVectorList()) return false;
    return (ARMMCRegisterClasses[ARM::DPairSpcRegClassID]
              .contains(VectorList.RegNum));
  }

Jim Grosbach has reviewed the change and said:  Yep, that sounds right. …
And by "right" I mean, "wow, that's a nasty latent bug I'm really, really
glad to see fixed." :)

rdar://16436683

llvm-svn: 204861

The tests are refactored to use the same fixture.

llvm-svn: 204860

This commit consist of two parts.
The first part fix the PR15967. The wrong conclusion was made when the MaxLookup
limit was reached. The fix introduce a out parameter (MaxLookupReached) to
DecomposeGEPExpression that the function aliasGEP can act upon.
The second part is introducing the constant MaxLookupSearchDepth to make sure
that DecomposeGEPExpression and GetUnderlyingObject use the same search depth.
This is a small cleanup to clarify the original algorithm.

Patch by Karl-Johan Karlsson!

llvm-svn: 204859

llvm-svn: 204857

Makes sure the Call dies before the Function

llvm-svn: 204856

llvm-svn: 204855

Expose the number of DFSan labels allocated by adding function dfsan_get_label_count().

Patch by Sam Kerner!

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

llvm-svn: 204854

llvm-svn: 204853

selectors because we were not going through entire
elements in list of all implemented selectors. 
// rdar://16428638

llvm-svn: 204852

In CallInst, op_end() points at the callee, which we don't want to iterate over
when just iterating over arguments. Now take this into account when returning
a iterator_range from arg_operands. Similar reasoning for InvokeInst.

Also adds a unit test to verify this actually works as expected.

llvm-svn: 204851

Use <mutex> instead of "llvm/Support/Mutex.h".

Also change the type of mutex for the context object to recursive mutex, as
the driver could acquire the lock recursively. E.g. If file A has .drectve
section containing /defaultlib:B, the driver tries to parse file B, and if
file B has .drectve section, the driver acquires the lock again.

llvm-svn: 204850

This commit also adds tests for std::numeric_limits<__[u]int128_t>.

Reviewed in http://llvm-reviews.chandlerc.com/D2917

llvm-svn: 204849

I've not yet updated PPCTTI because I'm not sure what the actual relative cost
is compared to the aligned uses.

llvm-svn: 204848

size 16 double-spaced registers instruction printing.

This:
	vld4.16 {d17[1], d19[1], d21[1], d23[1]}, [r7]!

was being printed as:

	vld4.16 {d17[1], d18[1], d19[1], d20[1]}, [r7]!

rdar://16435096

llvm-svn: 204847

llvm-svn: 204846

llvm-svn: 204845

We're already effectively checking sanity for that in PBQP::Graph::addEdge.

llvm-svn: 204844

llvm-svn: 204843

Edit by Daniel Fahlgren.

llvm-svn: 204842

The edge data structure (EdgeEntry) now holds the indices of its entries in the
adjacency lists of the nodes it connects. This trades a little ugliness for
faster insertion/removal, which is now O(1) with a cheap constant factor. All
of this is implementation detail within the PBQP graph, the external API remains
unchanged.

Individual register allocations are likely to change, since the adjacency lists
will now be ordered differently (or rather, will now be unordered). This
shouldn't affect the average quality of allocations however.

llvm-svn: 204841

This sext_inreg i32 in i64 case was already handled, but not enabled.

llvm-svn: 204840

These patterns are dead (because v4f32 stores are currently promoted to v4i32
and stored using Altivec instructions), and also are likely not correct
(because they'd store the vector elements in the opposite order from that
assumed by the rest of the Altivec code).

llvm-svn: 204839

These instructions have access to the complete VSX register file. In addition,
they "swap" the order of the elements so that element 0 (the scalar part) comes
first in memory and element 1 follows at a higher address.

llvm-svn: 204838

llvm-svn: 204837

Similar to r204835

llvm-svn: 204836