AArch64/ARM64: produce more informative diagnostic assembling some immediates

No tests here, they'll be added when the entire neon-diagnostics.s test from
AArch64 is enabled.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208079 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64/ARM64: add more specific diagnostic for invalid vector lanes

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208081 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64/ARM64: add more specific diagnostic for floating imm 0.0.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208082 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64/ARM64: make NEON vector list parsing a bit more robust

It doesn't change the results, but it seems silly not to diagnose obvious
problems early on.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208083 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64/ARM64: enable MC-level diagnostic tests for NEON insts.

Obviously we can't expect the two backends to produce identical diagnostics,
since what's possible depends quite a bit on how the .td files are structured.
I think the ARM64 diagnostics are basically of the same quality in all the
changed cases, so I've split the CHECK lines.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208084 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64/ARM64: add two more MC tests to ARM64 set.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208085 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64/ARM64: implement diagnosis of unpredictable loads & stores

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208091 91177308-0d34-0410-b5e6-96231b3b80d8
Be more strict about not calling setAlignment on global aliases.

The fact that GlobalAlias::setAlignment exists at all is a side effect of
how the classes are organized, it should never be used.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208094 91177308-0d34-0410-b5e6-96231b3b80d8
Be more strict about not allowing setSection on aliases.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208095 91177308-0d34-0410-b5e6-96231b3b80d8
Add some details to the llvm-cov documentation. <rdar://problem/15819496>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208098 91177308-0d34-0410-b5e6-96231b3b80d8
Have the SubtargetFeature help routine just not return a number and
fall back to the normal path without a cpu. While doing this fix
llc to just exit when we don't have a module to process instead of
asserting.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208102 91177308-0d34-0410-b5e6-96231b3b80d8
Special case aliases in GlobalValue::getAlignment.

An alias has the address of what it points to, so it also has the same
alignment.

This allows a few optimizations to see past aliases for free.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208103 91177308-0d34-0410-b5e6-96231b3b80d8
Implememting named register intrinsics

This patch implements the infrastructure to use named register constructs in
programs that need access to specific registers (bare metal, kernels, etc).

So far, only the stack pointer is supported as a technology preview, but as it
is, the intrinsic can already support all non-allocatable registers from any
architecture.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208104 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Improve the lowering of BITCAST dag nodes from type f64 to type v2i32 (and vice versa).

Before this patch, the backend always emitted a store+load sequence to
bitconvert from f64 to i64 the input operand of a ISD::BITCAST dag node that
performed a bitconvert from type MVT::f64 to type MVT::v2i32. The resulting
i64 node was then used to build a v2i32 vector.

With this patch, the backend now produces a cheaper SCALAR_TO_VECTOR from
MVT::f64 to MVT::v2f64. That SCALAR_TO_VECTOR is then followed by a "free"
bitcast to type MVT::v4i32. The elements of the resulting
v4i32 are then extracted to build a v2i32 vector (which is illegal and
therefore promoted to MVT::v2i64).

This is in general cheaper than emitting a stack store+load sequence
to bitconvert the operand from type f64 to type i64.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208107 91177308-0d34-0410-b5e6-96231b3b80d8
TTI: Estimate @llvm.fmuladd cost as fmul + fadd when FMA's aren't legal on the target.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208115 91177308-0d34-0410-b5e6-96231b3b80d8
Do not make -pass-remarks additive.

Summary:
When I initially introduced -pass-remarks, I thought it would be a
neat idea to make it additive. So, if one used it as:

$ llc -pass-remarks=inliner --pass-remarks=loop.*

the compiler would build the regular expression '(inliner)|(loop.*)'.

The more I think about it, the more I regret it. This is not how
other flags work. The standard semantics are right-to-left overrides.

This is how clang interprets -Rpass. And I think the two should be
compatible in this respect.

Reviewers: qcolombet

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208122 91177308-0d34-0410-b5e6-96231b3b80d8
Copy the full TailCallKind in CallInst::clone_impl

Split from the musttail inliner change.  This will be covered by an opt
test when the inliner change lands.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208126 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef-ize the Feature and Processor tables for SubtargetFeatures.
This removes arguments passed everywhere and allows the use of
standard iteration over lists.
Should be no functional change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208127 91177308-0d34-0410-b5e6-96231b3b80d8
If a function needs a frame pointer, but r11 (aka fp) has not been used,
remove it from the list of unspilled registers. Otherwise the following
attempt to keep the stack aligned by picking an extra GPR register to
spill will not work as it picks up r11.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208129 91177308-0d34-0410-b5e6-96231b3b80d8
Fix odd formatting that snuck into last patch.

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