| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 62262
|
| |
|
|
| |
llvm-svn: 62260
|
| |
|
|
| |
llvm-svn: 62127
|
| |
|
|
|
|
| |
suggested by Chris.
llvm-svn: 62099
|
| |
|
|
|
|
|
|
|
|
| |
promote from i1 all the way up to the canonical SetCC type.
In order to discover an appropriate type to use, pass
MVT::Other to getSetCCResultType. In order to be able to
do this, change getSetCCResultType to take a type as an
argument, not a value (this is also more logical).
llvm-svn: 61542
|
| |
|
|
| |
llvm-svn: 61463
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This removes all the _8, _16, _32, and _64 opcodes and replaces each
group with an unsuffixed opcode. The MemoryVT field of the AtomicSDNode
is now used to carry the size information. In tablegen, the size-specific
opcodes are replaced by size-independent opcodes that utilize the
ability to compose them with predicates.
This shrinks the per-opcode tables and makes the code that handles
atomics much more concise.
llvm-svn: 61389
|
| |
|
|
| |
llvm-svn: 61209
|
| |
|
|
| |
llvm-svn: 61129
|
| |
|
|
|
|
|
| |
target constants are allowed to have an illegal
type.
llvm-svn: 61006
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running /Users/void/llvm/llvm.src/test/CodeGen/Generic/dg.exp ...
FAIL: /Users/void/llvm/llvm.src/test/CodeGen/Generic/asm-large-immediate.ll
Failed with exit(1) at line 1
while running: llvm-as < /Users/void/llvm/llvm.src/test/CodeGen/Generic/asm-large-immediate.ll | llc | /usr/bin/grep 68719476738
Assertion failed: ((TypesNeedLegalizing || getTypeAction(VT) == Legal) && "Illegal type introduced after type legalization?"), function HandleOp, file /Users/void/llvm/llvm.src/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 493.
0 llc 0x0085392e char const* std::find<char const*, char>(char const*, char const*, char const&) + 98
1 llc 0x00853e63 llvm::sys::PrintStackTraceOnErrorSignal() + 593
2 libSystem.B.dylib 0x96cac09b _sigtramp + 43
3 libSystem.B.dylib 0xffffffff _sigtramp + 1765097359
4 libSystem.B.dylib 0x96d24ec2 raise + 26
5 libSystem.B.dylib 0x96d3447f abort + 73
6 libSystem.B.dylib 0x96d26063 __assert_rtn + 101
7 llc 0x004f9018 llvm::cast_retty<llvm::SubprogramDesc, llvm::DebugInfoDesc*>::ret_type llvm::cast<llvm::Sub
...
llvm-svn: 61001
|
| |
|
|
|
|
|
| |
types into the DAG if they were not already there.
Check this with an assertion.
llvm-svn: 60997
|
| |
|
|
| |
llvm-svn: 60974
|
| |
|
|
|
|
|
|
|
|
| |
width register load followed by a truncating
store for the copy, since the load will not place
the value in the lower bits. Probably partial
loads/stores can never happen here, but fix it
anyway.
llvm-svn: 60972
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use of illegal integer types: instead, use a stack slot
and copying via integer registers. The existing code
is still used if the bitconvert is to a legal integer
type.
This fires on the PPC testcases 2007-09-08-unaligned.ll
and vec_misaligned.ll. It looks like equivalent code
is generated with these changes, just permuted, but
it's hard to tell.
With these changes, nothing in LegalizeDAG produces
illegal integer types anymore. This is a prerequisite
for removing the LegalizeDAG type legalization code.
While there I noticed that the existing code doesn't
handle trunc store of f64 to f32: it turns this into
an i64 store, which represents a 4 byte stack smash.
I added a FIXME about this. Hopefully someone more
motivated than I am will take care of it.
llvm-svn: 60964
|
| |
|
|
|
|
| |
everyone is doing this these days :-). Patch by Daniel M Gessel!
llvm-svn: 60958
|
| |
|
|
|
|
|
|
| |
do an extending load of the 4 bytes rather than a
potentially illegal (type) i32 load followed by a
sign extend.
llvm-svn: 60945
|
| |
|
|
|
|
| |
Added support for TRUNC v8i16 to v8i8 for X86 (MMX)
llvm-svn: 60916
|
| |
|
|
| |
llvm-svn: 60866
|
| |
|
|
| |
llvm-svn: 60826
|
| |
|
|
|
|
|
| |
target-independent way of determining overflow on multiplication. It's very
tricky. Patch by Zoltan Varga!
llvm-svn: 60800
|
| |
|
|
|
|
| |
one of its operand.
llvm-svn: 60749
|
| |
|
|
|
|
|
|
| |
Fix the shift amount when unrolling a vector shift into scalar shifts.
Fix problem in getShuffleScalarElt where it assumes that the input of
a bit convert must be a vector.
llvm-svn: 60740
|
| |
|
|
|
|
| |
consistent with the way it's generally done in other places.
llvm-svn: 60439
|
| |
|
|
| |
llvm-svn: 60409
|
| |
|
|
| |
llvm-svn: 60406
|
| |
|
|
|
|
|
|
| |
MERGE_VALUES node with only one operand, so get
rid of special code that only existed to handle
that possibility.
llvm-svn: 60349
|
| |
|
|
|
|
|
|
|
|
|
| |
ReplaceNodeResults: rather than returning a node which
must have the same number of results as the original
node (which means mucking around with MERGE_VALUES,
and which is also easy to get wrong since SelectionDAG
folding may mean you don't get the node you expect),
return the results in a vector.
llvm-svn: 60348
|
| |
|
|
| |
llvm-svn: 60149
|
| |
|
|
| |
llvm-svn: 60102
|
| |
|
|
|
|
| |
differ. Thanks, Duncan.
llvm-svn: 60043
|
| |
|
|
| |
llvm-svn: 60016
|
| |
|
|
| |
llvm-svn: 60015
|
| |
|
|
|
|
|
| |
if the operands have the same sign and the sum has sign opposite to that of the
operands."
llvm-svn: 60014
|
| |
|
|
|
|
|
| |
- Mark "add with overflow" as having a custom lowering for X86. Give it a null
lowering representation for now.
llvm-svn: 59971
|
| |
|
|
| |
llvm-svn: 59952
|
| |
|
|
| |
llvm-svn: 59926
|
| |
|
|
|
|
| |
- Add "promote integer type" stuff to the legalizer for these nodes.
llvm-svn: 59847
|
| |
|
|
|
|
|
| |
and when loading/storing a widen vector, make sure that they are loaded
and stored in consecutive order.
llvm-svn: 59357
|
| |
|
|
|
|
|
| |
support targets that support these conversions. Users should avoid using
this node as the current targets don't generating code for it.
llvm-svn: 59001
|
| |
|
|
|
|
| |
<result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <m x i32> <mask>
llvm-svn: 58964
|
| |
|
|
|
|
|
|
|
|
| |
This is Chris' patch from the PR, modified to realize that
SETUGT/SETULT occur legitimately with integers, plus
two fixes in LegalizeDAG to pass a valid result type into
LegalizeSetCC. The argument of TLI.getSetCCResultType is
ignored on PPC, but I think I'm following usage elsewhere.
llvm-svn: 58871
|
| |
|
|
|
|
| |
when simplify a vector.
llvm-svn: 58820
|
| |
|
|
| |
llvm-svn: 58796
|
| |
|
|
| |
llvm-svn: 58717
|
| |
|
|
|
|
| |
10 bytes long, but is passed in 12/16 bytes).
llvm-svn: 58608
|
| |
|
|
| |
llvm-svn: 58443
|
| |
|
|
|
|
|
| |
One will only see an effect if legalizetype is not active. Will move
support to LegalizeType soon.
llvm-svn: 58426
|
| |
|
|
|
|
|
|
|
|
| |
The same one Apple gcc uses, faster. Also gets the
extreme case in gcc.c-torture/execute/ieee/rbug.c
correct which we weren't before; this is not
sufficient to get the test to pass though, there
is another bug.
llvm-svn: 57926
|
| |
|
|
|
|
| |
that NaNs are less common.
llvm-svn: 57871
|