R600/SI: Add FMA pattern

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188135 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: FMA is faster than fmul and fadd for f64

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188136 91177308-0d34-0410-b5e6-96231b3b80d8
Teach ValueTracking about address spaces

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188140 91177308-0d34-0410-b5e6-96231b3b80d8
[Sparc] Enable xword directive in sparcv9.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188141 91177308-0d34-0410-b5e6-96231b3b80d8
Revert r188119 "Kill some duplicated code for removing unreachable BBs."

It is breaking builbots with libgmalloc enabled on Mac OS X.

$ cd llvm ; mkdir release ; cd release
$ ../configure --enable-optimized —prefix=$PWD/install
$ make
$ make check
$ Release+Asserts/bin/llvm-lit -v --param use_gmalloc=1 --param \
  gmalloc_path=/usr/lib/libgmalloc.dylib \
  ../test/Instrumentation/DataFlowSanitizer/args-unreachable-bb.ll

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188142 91177308-0d34-0410-b5e6-96231b3b80d8
Incorrect JAL instruction attributes caused the optimizer to make a wrong
instruction move. Just affects static relocation. -static works fine now
with mips16 for the most part.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188143 91177308-0d34-0410-b5e6-96231b3b80d8
Reformat some bits of AllocaPromoter and simplify the name and type of
our visiting datastructures in the AllocaPromoter/SSAUpdater path of
SROA. Also shift the order if clears around to be more consistent.

No functionality changed here, this is just a cleanup.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188144 91177308-0d34-0410-b5e6-96231b3b80d8
Finish fixing the SSAUpdater-based AllocaPromoter strategy in SROA to cope with
the more general set of patterns that are now handled by mem2reg and that we
can detect quickly while doing SROA's initial analysis. Notably, this allows it
to promote through no-op bitcast and GEP sequences. A core part of the
SSAUpdater approach is the ability to test whether a particular instruction is
part of the set being promoted. Testing this becomes significantly more complex
in the world where the operand to every load and store isn't the alloca itself.
I ended up using the approach of walking up the def-chain until we find the
alloca. I benchmarked this against keeping a set of pointer operands and
keeping a set of the loads and stores we care about, and this one seemed faster
although the difference was very small.

No test case yet because currently the rewriting always "fixes" the inputs to
not require this. The next patch which re-enables early promotion of easy cases
in SROA will include a test case that specifically exercises this aspect of the
alloca promoter.

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