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
Re-instate r187323 which fast-tracks promotable allocas as soon as the
SROA-based analysis has enough information. This should work now that
both mem2reg *and* the SSAUpdater-based AllocaPromoter have been updated
to be able to promote the types of allocas that the SROA analysis
detects.

I've included tests for the AllocaPromoter that were only possible to
write once we fast-tracked promotable allocas without rewriting them.
This includes a test both for r187347 and r188145.

Original commit log for r187323:
"""
Now that mem2reg understands how to cope with a slightly wider set of uses of
an alloca, we can pre-compute promotability while analyzing an alloca for
splitting in SROA. That lets us short-circuit the common case of a bunch of
trivially promotable allocas. This cuts 20% to 30% off the run time of SROA for
typical frontend-generated IR sequneces I'm seeing. It gets the new SROA to
within 20% of ScalarRepl for such code. My current benchmark for these numbers
is PR15412, but it fits the general pattern of IR emitted by Clang so it should
be widely applicable.
"""

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188146 91177308-0d34-0410-b5e6-96231b3b80d8
AVX-512: Added VPERM* instructons and MOV* zmm-to-zmm instructions.
Added a test for shuffles using VPERM.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188147 91177308-0d34-0410-b5e6-96231b3b80d8
AVX-512: Added more tests for BROADCAST


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188148 91177308-0d34-0410-b5e6-96231b3b80d8
Don't generate floating point stubs for mips16 code if the function
is actually an instrinsic that will not occur in libc. This list here
is not exhaustive but fixes the one places in test-suite where this occurs.
I have filed a bug against myself to research the full list and add them
to the array of such cases. In the future, actual stub generation will occur
in a later phase and we won't need this code because we will know at that time
during the compilation that in fact no helper function was even needed.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188149 91177308-0d34-0410-b5e6-96231b3b80d8
Fix big-endian handling of integer-to-vector bitcasts in InstCombine

These functions used to assume that the lsb of an integer corresponds
to vector element 0, whereas for big-endian it's the other way around:
the msb is in the first element and the lsb is in the last element.

Fixes MultiSource/Benchmarks/mediabench/gsm/toast for z.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188155 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce factory methods for SpecialCaseList

Summary:
Doing work in constructors is bad: this change suggests to
call SpecialCaseList::create(Path, Error) instead of
"new SpecialCaseList(Path)". Currently the latter may crash with
report_fatal_error, which is undesirable - sometimes we want to report
the error to user gracefully - for example, if he provides an incorrect
file as an argument of Clang's -fsanitize-blacklist flag.

Reviewers: pcc

Reviewed By: pcc

CC: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188156 91177308-0d34-0410-b5e6-96231b3b80d8
Relax conditions of test added in r188156 to fix it on Windows

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188157 91177308-0d34-0410-b5e6-96231b3b80d8
Remove global construction. const char* is sufficient here.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188158 91177308-0d34-0410-b5e6-96231b3b80d8
Allow compatible extension attributes for tail calls

If the tail-callee and caller give the same bits via the same signext/zeroext
attribute then a tail-call should be allowed, since the extension has already
been done by the callee.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188159 91177308-0d34-0410-b5e6-96231b3b80d8
Target a minimal terminfo library rather than necessarily a full curses
library for color support detection. This still will use a curses
library if that is all we have available on the system. This change
tries to use a smaller subset of the curses library, specifically the
subset that is on some systems split off into a separate library. For
example, if you install ncurses configured --with-tinfo, a 'libtinfo' is
install that provides just the terminfo querying functionality. That
library is now used instead of curses when it is available.

This happens to fix a build error on systems with that library because
when we tried to link ncurses into the binary, we didn't pull tinfo in
as well. =]

It should also provide an easy path for supporting the NetBSD
libterminfo library, but as I don't have access to a NetBSD system I'm
leaving adding that support to those folks.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188160 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Add a definition of the IPM instruction


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188161 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Add a definition of the CLC instruction


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