| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
nodes with operand types that differ from the result type. (This
doesn't normally happen right now, because
SelectionDAGLowering::visitShuffleVector normalizes vector shuffles.)
llvm-svn: 75081
|
| |
|
|
| |
llvm-svn: 75067
|
| |
|
|
|
|
|
|
| |
number of elements. Make some simplifications based
on this (in particular SplitVecRes_SETCC). Tighten
up some checking while there.
llvm-svn: 75050
|
| |
|
|
|
|
| |
and cases alphabetically. No functionality change.
llvm-svn: 75001
|
| |
|
|
|
|
|
| |
these instructions, no autoupgrade or backwards compatibility support is
provided.
llvm-svn: 74991
|
| |
|
|
|
|
|
|
|
| |
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
llvm-svn: 74978
|
| |
|
|
|
|
| |
for now, conservatively return false.
llvm-svn: 74969
|
| |
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 74967
|
| |
|
|
|
|
| |
the input is legal (4 x i32)
llvm-svn: 74964
|
| |
|
|
| |
llvm-svn: 74962
|
| |
|
|
|
|
|
| |
finishes off enough support for vector compares to get the icmp/fcmp
version of 2008-07-23-VSetCC.ll passing.
llvm-svn: 74961
|
| |
|
|
|
|
| |
(vector of bool).
llvm-svn: 74960
|
| |
|
|
|
|
| |
eliminate the former.
llvm-svn: 74959
|
| |
|
|
| |
llvm-svn: 74957
|
| |
|
|
| |
llvm-svn: 74931
|
| |
|
|
|
|
|
|
|
|
|
| |
arguments in a vararg call.
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.
llvm-svn: 74764
|
| |
|
|
| |
llvm-svn: 74733
|
| |
|
|
| |
llvm-svn: 74720
|
| |
|
|
| |
llvm-svn: 74677
|
| |
|
|
| |
llvm-svn: 74673
|
| |
|
|
| |
llvm-svn: 74659
|
| |
|
|
| |
llvm-svn: 74625
|
| |
|
|
|
|
|
|
|
|
| |
operand is defined by an implicit_def. That means it can def / use any register and passes (e.g. register scavenger) can feel free to ignore them.
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.
llvm-svn: 74518
|
| |
|
|
| |
llvm-svn: 74364
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 74325
|
| |
|
|
|
|
| |
SDNode::print_details to eliminate a ton of near-duplicate code.
llvm-svn: 74311
|
| |
|
|
|
|
| |
but in the meantime lets print targetflags on node labels.
llvm-svn: 74274
|
| |
|
|
| |
llvm-svn: 74273
|
| |
|
|
| |
llvm-svn: 74270
|
| |
|
|
| |
llvm-svn: 74204
|
| |
|
|
| |
llvm-svn: 74203
|
| |
|
|
| |
llvm-svn: 74199
|
| |
|
|
|
|
|
|
| |
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!
llvm-svn: 74180
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 74110
|
| |
|
|
|
|
|
|
| |
through the GraphViz rendering code.
Update other uses in the codebase for this change.
llvm-svn: 74084
|
| |
|
|
| |
llvm-svn: 74082
|
| |
|
|
| |
llvm-svn: 74065
|
| |
|
|
|
|
|
| |
types for the target (I think). This was breaking
the PPC32 calling sequence.
llvm-svn: 73900
|
| |
|
|
| |
llvm-svn: 73786
|
| |
|
|
|
|
| |
taking so long to get to this!
llvm-svn: 73757
|
| |
|
|
| |
llvm-svn: 73483
|
| |
|
|
|
|
| |
operations).
llvm-svn: 73480
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 73477
|
| |
|
|
|
|
| |
unsupported inline asm construct, rather than verifying a code invariant.
llvm-svn: 73435
|
| |
|
|
| |
llvm-svn: 73426
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 73387
|
| |
|
|
|
|
| |
converting from an MMX vector to an i64.
llvm-svn: 73024
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 73012
|
| |
|
|
|
|
| |
types.
llvm-svn: 72993
|
| |
|
|
| |
llvm-svn: 72992
|