[mips][fp64a] Temporarily disable odd-numbered double-precision registers when using the FP64A ABI.

Summary:
A few instructions (mostly cvt.d.w and similar) are causing problems with
-mfp64 and -mno-odd-spreg and it looks like fixing it properly may
take several weeks. In the meantime, let's disable the odd-numbered
double-precision registers so that the generated code is at least valid.

The problem is that instructions like cvt.d.w read from the 32-bit low
subregister of a double-precision FPU register. This often leads to the compiler
to inserting moves to transfer a GPR32 to a FGR32 using mtc1. Such moves
violate the rules against 32-bit writes to odd-numbered FPU registers imposed
by -mno-odd-spreg. By disabling the odd-numbered double-precision registers, it
becomes impossible for the 32-bit low subregister to be odd-numbered.

This fixes numerous test-suite failures when compiling for the FP64A ABI
('-mfp64 -mno-odd-spreg'). There is no LLVM test case because it's difficult to
test that odd-numbered FPU registers are not allocatable. Instead, we depend on
the assembler (GAS and -fintegrated-as) raising errors when the rules are
violated.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213160 91177308-0d34-0410-b5e6-96231b3b80d8
Convert test to CHECK-LABEL

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213161 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen: don't form illegail EXTLOAD operations.

It turns out that in most cases (the main exception being i1-related
types) once these operations are formed we cannot separate them and
the targets end up having to deal with them whether they want to or
not.

This is not a good situation, and a more reasonable default can be
formed by ackowledging this and having targets leave them as Legal.
Only x86 seems to be affected (other targets don't even try marking
the operation Expand).

Mostly there's no visible change here yet, but it will be useful to
have truly expanded EXTLOADS for MVT::f16 softening support.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213162 91177308-0d34-0410-b5e6-96231b3b80d8
[NVPTX] Rename registers %fl -> %fd and %rl -> %rd

This matches the internal behavior of NVIDIA tools like libnvvm.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213168 91177308-0d34-0410-b5e6-96231b3b80d8
Added documentation for SizeMultiplier in the ARM subtarget hook for register coalescing. Also fixed some 80 col violations.

No functional code changes.

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

The clang rewriter is now a core facility.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213173 91177308-0d34-0410-b5e6-96231b3b80d8
Remove unnecessary/redundant std::move

(run returns unique_ptr by value already)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213174 91177308-0d34-0410-b5e6-96231b3b80d8
Add the "-x" flag to llvm-nm for Mach-O files that prints the fields of a symbol in hex.
(generally use for debugging the tools).  This is same functionality as darwin’s
nm(1) "-x" flag.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213176 91177308-0d34-0410-b5e6-96231b3b80d8
CHECK-LABEL-ize one test

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213177 91177308-0d34-0410-b5e6-96231b3b80d8
[NVPTX] Honor alignment on vector loads/stores

We were not considering the stated alignment on vector loads/stores,
leading us to generate vector instructions even when we do not have
sufficient alignment.

Now, for IR like:

  %1 = load <4 x float>, <4 x float>* %ptr, align 4

we will generate correct, conservative PTX like:

  ld.f32 ... [%ptr]
  ld.f32 ... [%ptr+4]
  ld.f32 ... [%ptr+8]
  ld.f32 ... [%ptr+12]

Or if we have an alignment of 8 (for example), we can
generate code like:

  ld.v2.f32 ... [%ptr]
  ld.v2.f32 ... [%ptr+8]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213186 91177308-0d34-0410-b5e6-96231b3b80d8
[RegisterCoalescer] Moving the RegisterCoalescer subtarget hook onto the TargetRegisterInfo instead of the TargetSubtargetInfo.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213188 91177308-0d34-0410-b5e6-96231b3b80d8
Utilize CastInst::CreatePointerBitCastOrAddrSpaceCast here.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213189 91177308-0d34-0410-b5e6-96231b3b80d8
Remove Atom references in description.

Any CPU can run this pass.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213190 91177308-0d34-0410-b5e6-96231b3b80d8
trivial fix for PR20314

Make sure that the AddrInst is an Instruction.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213197 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a typo in the inalloca description

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213200 91177308-0d34-0410-b5e6-96231b3b80d8
[MCJIT] Improve a RuntimeDyldChecker diagnostic.

When a RuntimeDyldChecker test requests an invalid operand for an instruction,
print the decoded instruction to aid diagnosis.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213202 91177308-0d34-0410-b5e6-96231b3b80d8
[FastISel] Local values shouldn't be alive across an inline asm call with side effects.

This fixes an issue where a local value is defined before and used after an
inline asm call with side effects.

This fix simply flushes the local value map, which updates the insertion point
for the inline asm call to be above any previously defined local values.

This fixes <rdar://problem/17694203>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213203 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed formatting, removed bug reference, renamed testcase

Thanks to Duncan Exon Smith for reviewing and cleanup suggestions. 


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213205 91177308-0d34-0410-b5e6-96231b3b80d8
Partially revert r210444 due to performance regression

Summary:
Converting outermost zext(a) to sext(a) causes worse code when the
computation of zext(a) could be reused. For example, after converting

... = array[zext(a)]
... = array[zext(a) + 1]

to

... = array[sext(a)]
... = array[zext(a) + 1],

the program computes sext(a), which is actually unnecessary. I added one
test in split-gep-and-gvn.ll to illustrate this scenario.

Also, with r211281 and r211084, we annotate more "nuw" tags to
computation involving CUDA intrinsics such as threadIdx.x. These
annotations help with splitting GEP a lot, rendering the benefit we get
from this reverted optimization only marginal.

Test Plan: make check-all

Reviewers: eliben, meheff

Reviewed By: meheff

Subscribers: jholewinski, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213209 91177308-0d34-0410-b5e6-96231b3b80d8
Improve BasicAA CS-CS queries (redux)

This reverts, "r213024 - Revert r212572 "improve BasicAA CS-CS queries", it
causes PR20303." with a fix for the bug in pr20303. As it turned out, the
relevant code was both wrong and over-conservative (because, as with the code
it replaced, it would return the overall ModRef mask even if just Ref had been
implied by the argument aliasing results). Hopefully, this correctly fixes both
problems.

Thanks to Nick Lewycky for reducing the test case for pr20303 (which I've
cleaned up a little and added in DSE's test directory). The BasicAA test has
also been updated to check for this error.

Original commit message:

BasicAA contains knowledge of certain intrinsics, such as memcpy and memset,
and uses that information to form more-accurate answers to CallSite vs. Loc
ModRef queries. Unfortunately, it did not use this information when answering
CallSite vs. CallSite queries.

Generically, when an intrinsic takes one or more pointers and the intrinsic is
marked only to read/write from its arguments, the offset/size is unknown. As a
result, the generic code that answers CallSite vs. CallSite (and CallSite vs.
Loc) queries in AA uses UnknownSize when forming Locs from an intrinsic's
arguments. While BasicAA's CallSite vs. Loc override could use more-accurate
size information for some intrinsics, it did not do the same for CallSite vs.
CallSite queries.

This change refactors the intrinsic-specific logic in BasicAA into a generic AA
query function: getArgLocation, which is overridden by BasicAA to supply the
intrinsic-specific knowledge, and used by AA's generic implementation. This
allows the intrinsic-specific knowledge to be used by both CallSite vs. Loc and
CallSite vs. CallSite queries, and simplifies the BasicAA implementation.

Currently, only one function, Mac's memset_pattern16, is handled by BasicAA
(all the rest are intrinsics). As a side-effect of this refactoring, BasicAA's
getModRefBehavior override now also returns OnlyAccessesArgumentPointees for
this function (which is an improvement).

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