nodes with operand types that differ from the result type. (This
doesn't normally happen right now, because
SelectionDAGLowering::visitShuffleVector normalizes vector shuffles.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75081 91177308-0d34-0410-b5e6-96231b3b80d8
number of elements. Make some simplifications based
on this (in particular SplitVecRes_SETCC). Tighten
up some checking while there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75050 91177308-0d34-0410-b5e6-96231b3b80d8
VSETCC must define all bits, which is different than it was documented
to before. Since all targets that implement VSETCC already have this
behavior, and we don't optimize based on this, just change the
documentation. We now get nice code for vec_compare.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74978 91177308-0d34-0410-b5e6-96231b3b80d8
as "X" constraint and "P" modifier on x86. Make this work.
(Change may not be sufficient to fix it for non-Darwin, but
I'm pretty sure it won't break anything.)
gcc.apple/asm-block-32.c
gcc.apple/asm-block-33.c
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74967 91177308-0d34-0410-b5e6-96231b3b80d8
finishes off enough support for vector compares to get the icmp/fcmp
version of 2008-07-23-VSetCC.ll passing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74961 91177308-0d34-0410-b5e6-96231b3b80d8
With the SVR4 ABI on PowerPC, vector arguments for vararg calls are passed differently depending on whether they are a fixed or a variable argument. Variable vector arguments always go into memory, fixed vector arguments are put
into vector registers. If there are no free vector registers available, fixed vector arguments are put on the stack.
The NumFixedArgs attribute allows to decide for an argument in a vararg call whether it belongs to the fixed or variable portion of the parameter list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74764 91177308-0d34-0410-b5e6-96231b3b80d8
The register allocator, when it allocates a register to a virtual register defined by an implicit_def, can allocate any physical register without worrying about overlapping live ranges. It should mark all of operands of the said virtual register so later passes will do the right thing.
This is not the best solution. But it should be a lot less fragile to having the scavenger try to track what is defined by implicit_def.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74518 91177308-0d34-0410-b5e6-96231b3b80d8
the SelectionDAG::getGlobalAddress function properly looks through
aliases to determine thread-localness, but then passes the GV* down
to GlobalAddressSDNode::GlobalAddressSDNode which does not. Instead
of passing down isTarget, just pass down the predetermined node
opcode. This fixes some assertions with out of tree changes I'm
working on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74325 91177308-0d34-0410-b5e6-96231b3b80d8
to be shared, but how/where to privatize it is not immediately clear to me.
If any SelectionDAG experts see a better solution, please share!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74180 91177308-0d34-0410-b5e6-96231b3b80d8
This change doubles the allowable value for MVT::LAST_VALUETYPE. It does
this by doing several things.
1. Introduces MVT::MAX_ALLOWED_LAST_VALUETYPE which in this change has a
value of 64. This value contains the current maximum for the
MVT::LAST_VALUETYPE.
2. Instead of checking "MVT::LAST_VALUETYPE <= 32", all of those uses
now become "MVT::LAST_VALUETYPE <= MVT::MAX_ALLOWED_LAST_VALUETYPE"
3. Changes the dimension of the ValueTypeActions from 2 elements to four
elements and adds comments ahead of the declaration indicating the it is
"(MVT::MAX_ALLOWED_LAST_VALUETYPE/32) * 2". This at least lets us find
what is affected if and when MVT::MAX_ALLOWED_LAST_VALUETYPE gets
changed.
4. Adds initializers for the new elements of ValueTypeActions.
This does NOT add any types in MVT. That would be done separately.
This doubles the size of ValueTypeActions from 64 bits to 128 bits and
gives us the freedom to add more types for AVX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74110 91177308-0d34-0410-b5e6-96231b3b80d8
support for x86, and UMULO/SMULO for many architectures, including PPC
(PR4201), ARM, and Cell. The resulting expansion isn't perfect, but it's
not bad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73477 91177308-0d34-0410-b5e6-96231b3b80d8
incomming chain of the RETURN node. The incomming chain must
be the outgoing chain of the CALL node. This causes the
backend to identify tail calls that are not tail calls. This
patch fixes this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73387 91177308-0d34-0410-b5e6-96231b3b80d8
on x86 to handle more cases. Fix a bug in said code that would cause it
to read past the end of an object. Rewrite the code in
SelectionDAGLegalize::ExpandBUILD_VECTOR to be a bit more general.
Remove PerformBuildVectorCombine, which is no longer necessary with
these changes. In addition to simplifying the code, with this change,
we can now catch a few more cases of consecutive loads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73012 91177308-0d34-0410-b5e6-96231b3b80d8
