It is temporary patch. We need to keep it in trunk, since it makes easer to test it on buildbots on different platforms.
Once we see stable MergeFunctions behaviour with satisfied perfomance, this patch will be removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191331 91177308-0d34-0410-b5e6-96231b3b80d8
Some supplemental information for r191314: We would like to make sure SLP Vectorizer will not try to vectorize tiny trees even with a negative threshold so we set the cost to INT_MAX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191327 91177308-0d34-0410-b5e6-96231b3b80d8
This code isn't ready to deal with allocation functions where the return is not
the allocated pointer. The checks below will reject posix_memalign anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191319 91177308-0d34-0410-b5e6-96231b3b80d8
This is safe per C++11 18.6.1.1p3: [operator new returns] a non-null pointer to
suitably aligned storage (3.7.4), or else throw a bad_alloc exception. This
requirement is binding on a replacement version of this function.
Brings us a tiny bit closer to eliminating more vector push_backs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191310 91177308-0d34-0410-b5e6-96231b3b80d8
Most constant BUILD_VECTOR's are matched using ComplexPatterns which cover
bitcasted as well as normal vectors. However, it doesn't seem to be possible to
match ldi.[bhwd] in a type-agnostic manner (e.g. to support the widest range of
immediates, it should be possible to use ldi.b to load v2i64) using TableGen so
ldi.[bhwd] is matched using custom code in MipsSEISelDAGToDAG.cpp
This made the majority of the constant splat BUILD_VECTOR lowering redundant.
The only transformation remaining for constant splats is when an (up-to) 32-bit
constant splat is possible but the value does not fit into a 10-bit signed
integer. In this case, the BUILD_VECTOR is transformed into a bitcasted
BUILD_VECTOR so that fill.[bhw] can be used to splat the vector from a GPR32
register (which is initialized using the usual lui/addui sequence).
There are no additional tests since this is a re-implementation of previous
functionality. The change is intended to make it easier to implement some of
the upcoming instruction selection patches since they can rely on existing
support for BUILD_VECTOR's in the DAGCombiner.
compare_float.ll changed slightly because a BITCAST is no longer
introduced during legalization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191299 91177308-0d34-0410-b5e6-96231b3b80d8
MIPS SelectionDAG changes:
* Added VCEQ, VCL[ET]_[SU] nodes to represent vector comparisons that produce a bitmask.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191286 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure that the code that handles the constant addresses is run for the
GEPs. This just refactors that code and then calls it for the GEPs that are
collected during the iteration.
<rdar://problem/12445434>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191281 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Ana Pazos.
1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arithmetic instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191263 91177308-0d34-0410-b5e6-96231b3b80d8
Sometimes a copy from a vreg -> vreg sneaks into the middle of a terminator
sequence. It is safe to slice this into the stack protector success bb.
This fixes PR16979.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191260 91177308-0d34-0410-b5e6-96231b3b80d8
The order in which the comdat type unit sections appear in the output is
unspecified and may vary from machine to machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191253 91177308-0d34-0410-b5e6-96231b3b80d8
The recursive nature of the address selection code can cause the stack to
explode if there is a long chain of GEPs. Convert the recursive bit into a
iterative method to avoid this.
<rdar://problem/12445434>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191252 91177308-0d34-0410-b5e6-96231b3b80d8
The underlying type of all plain enums in MSVC is 'int', even if the
enumerator contains large 32-bit unsigned values or values greater than
UINT_MAX. The only way to get a large or unsigned enum type is to
request it explicitly with the C++11 strong enum types feature.
However, since LLVM isn't C++11 yet, I had to add a conditional
LLVM_ENUM_INT_TYPE to Compiler.h to control its usage.
The motivating true positive for this change is compiling PointerIntPair
with MSVC for win64. The PointerIntMask value is supposed to be pointer
sized value of all ones with some low zeros. Instead, it's truncated to
32-bits! We are only saved later because it is sign extended back in
the AND with int64_t, and we happen to want all ones.
This silences lots of -Wmicrosoft warnings during a clang self-host
targeting Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191241 91177308-0d34-0410-b5e6-96231b3b80d8
