Fix a problem with the ARM assembler incorrectly matching a
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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204861 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-cov: Handle functions with no line number

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204863 91177308-0d34-0410-b5e6-96231b3b80d8
Add comments. Addressing review comments from Evan on r204690.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204864 91177308-0d34-0410-b5e6-96231b3b80d8
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.




git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204865 91177308-0d34-0410-b5e6-96231b3b80d8
CloneFunction: Clone all attributes, including the CC

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204866 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-cov: Disable test on big endian machines

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204868 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-cov: Move XFAIL after the body of the test

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204871 91177308-0d34-0410-b5e6-96231b3b80d8