summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Change legalizeop of FP_ROUND and FP_EXTEND to not fall throughChris Lattner2008-01-161-32/+55
| | | | | | | | | into the ANY_EXTEND/ZERO_EXTEND/SIGN_EXTEND code to simplify it. Unmerge the code for FP_ROUND and FP_EXTEND from each other to make each one simpler. llvm-svn: 46061
* The type of the 'abort' node should be pointer type (becauseChris Lattner2008-01-151-1/+2
| | | | | | | it's a function pointer) not MVT::Other. This fixes builtin_trap lowering on ppc, alpha, ia64 llvm-svn: 46018
* Add support for targets that have a legal ISD::TRAP.Chris Lattner2008-01-151-4/+9
| | | | llvm-svn: 46014
* For PR1839: add initial support for __builtin_trap. llvm-gcc part is missedAnton Korobeynikov2008-01-151-0/+19
| | | | | | as well as PPC codegen llvm-svn: 46001
* Output sinl for a long double FSIN node, not sin.Duncan Sands2008-01-101-53/+52
| | | | | | | | Likewise fix up a bunch of other libcalls. While there I remove NEG_F32 and NEG_F64 since they are not used anywhere. This fixes 9 Ada ACATS failures. llvm-svn: 45833
* If custom lowering of insert element fails, the result Val will be 0.Nate Begeman2008-01-051-3/+3
| | | | | | | Don't overwrite a variable used by the fallthrough code path in this case. llvm-svn: 45630
* Fix PR1833 - eh.exception and eh.selector return twoDuncan Sands2007-12-311-6/+28
| | | | | | | | values, which means doing extra legalization work. It would be easier to get this kind of thing right if there was some documentation... llvm-svn: 45472
* Rename SSARegMap -> MachineRegisterInfo in keeping with the idea Chris Lattner2007-12-311-0/+1
| | | | | | | | | | | | | | that "machine" classes are used to represent the current state of the code being compiled. Given this expanded name, we can start moving other stuff into it. For now, move the UsedPhysRegs and LiveIn/LoveOuts vectors from MachineFunction into it. Update all the clients to match. This also reduces some needless #includes, such as MachineModuleInfo from MachineFunction. llvm-svn: 45467
* Remove attribution from file headers, per discussion on llvmdev.Chris Lattner2007-12-291-2/+2
| | | | llvm-svn: 45418
* Implement expand support for MERGE_VALUEs that only produces one result.Chris Lattner2007-11-241-0/+4
| | | | llvm-svn: 44304
* Several changes:Chris Lattner2007-11-241-9/+31
| | | | | | | | | | | | | | | | | | | | | 1) Change the interface to TargetLowering::ExpandOperationResult to take and return entire NODES that need a result expanded, not just the value. This allows us to handle things like READCYCLECOUNTER, which returns two values. 2) Implement (extremely limited) support in LegalizeDAG::ExpandOp for MERGE_VALUES. 3) Reimplement custom lowering in LegalizeDAGTypes in terms of the new ExpandOperationResult. This makes the result simpler and fully general. 4) Implement (fully general) expand support for MERGE_VALUES in LegalizeDAGTypes. 5) Implement ExpandOperationResult support for ARM f64->i64 bitconvert and ARM i64 shifts, allowing them to work with LegalizeDAGTypes. 6) Implement ExpandOperationResult support for X86 READCYCLECOUNTER and FP_TO_SINT, allowing them to work with LegalizeDAGTypes. LegalizeDAGTypes now passes several more X86 codegen tests when enabled and when type legalization in LegalizeDAG is ifdef'd out. llvm-svn: 44300
* ExpandUnalignedLoad doesn't handle vectors right at all apparently.Chris Lattner2007-11-191-8/+22
| | | | | | | | | | | | | | | Fix a couple of problems: 1. Don't assume the VT-1 is a VT that is half the size. 2. Treat vectors of FP in the vector path, not the FP path. This has a couple of remaining problems before it will work with the code in PR1811: the code below this change assumes that it can use extload/shift/or to construct the result, which isn't right for vectors. This also doesn't handle vectors of 1 or vectors that aren't pow-2. llvm-svn: 44243
* Implement vector expand support for shuffle_vector. This fixes PR1811.Chris Lattner2007-11-191-0/+35
| | | | llvm-svn: 44242
* Implement splitting of UNDEF nodes. This is the first step towards fixing PR1811Chris Lattner2007-11-191-0/+4
| | | | llvm-svn: 44239
* Add support in SplitVectorOp for remainder operators.Dan Gohman2007-11-191-1/+4
| | | | llvm-svn: 44233
* Add support for vectors to int <-> float casts.Nate Begeman2007-11-171-1/+5
| | | | llvm-svn: 44204
* Implement necessary bits for flt_rounds gcc builtin. Anton Korobeynikov2007-11-151-0/+14
| | | | | | Codegen bits and llvm-gcc support will follow. llvm-svn: 44182
* Basic non-power-of-2 vector supportNate Begeman2007-11-151-29/+37
| | | | llvm-svn: 44181
* Unify CALLSEQ_{START,END}. They take 4 parameters: the chain, two stackBill Wendling2007-11-131-2/+23
| | | | | | | | | | | adjustment fields, and an optional flag. If there is a "dynamic_stackalloc" in the code, make sure that it's bracketed by CALLSEQ_START and CALLSEQ_END. If not, then there is the potential for the stack to be changed while the stack's being used by another instruction (like a call). This can only result in tears... llvm-svn: 44037
* Move MinAlign to MathExtras.h.Duncan Sands2007-11-091-1/+0
| | | | llvm-svn: 43944
* Much improved pic jumptable codegen:Evan Cheng2007-11-091-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Then: call "L1$pb" "L1$pb": popl %eax ... LBB1_1: # entry imull $4, %ecx, %ecx leal LJTI1_0-"L1$pb"(%eax), %edx addl LJTI1_0-"L1$pb"(%ecx,%eax), %edx jmpl *%edx .align 2 .set L1_0_set_3,LBB1_3-LJTI1_0 .set L1_0_set_2,LBB1_2-LJTI1_0 .set L1_0_set_5,LBB1_5-LJTI1_0 .set L1_0_set_4,LBB1_4-LJTI1_0 LJTI1_0: .long L1_0_set_3 .long L1_0_set_2 Now: call "L1$pb" "L1$pb": popl %eax ... LBB1_1: # entry addl LJTI1_0-"L1$pb"(%eax,%ecx,4), %eax jmpl *%eax .align 2 .set L1_0_set_3,LBB1_3-"L1$pb" .set L1_0_set_2,LBB1_2-"L1$pb" .set L1_0_set_5,LBB1_5-"L1$pb" .set L1_0_set_4,LBB1_4-"L1$pb" LJTI1_0: .long L1_0_set_3 .long L1_0_set_2 llvm-svn: 43924
* Didn't mean to check these in.Evan Cheng2007-11-091-7/+11
| | | | llvm-svn: 43923
* Bug fix. Passive nodes are not in SUnitMap.Evan Cheng2007-11-091-11/+7
| | | | llvm-svn: 43922
* Remainder operations must be either integer or floating-point.Dan Gohman2007-11-061-1/+3
| | | | llvm-svn: 43781
* Add support for vector remainder operations.Dan Gohman2007-11-051-7/+13
| | | | llvm-svn: 43744
* Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.Duncan Sands2007-11-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The meaning of getTypeSize was not clear - clarifying it is important now that we have x86 long double and arbitrary precision integers. The issue with long double is that it requires 80 bits, and this is not a multiple of its alignment. This gives a primitive type for which getTypeSize differed from getABITypeSize. For arbitrary precision integers it is even worse: there is the minimum number of bits needed to hold the type (eg: 36 for an i36), the maximum number of bits that will be overwriten when storing the type (40 bits for i36) and the ABI size (i.e. the storage size rounded up to a multiple of the alignment; 64 bits for i36). This patch removes getTypeSize (not really - it is still there but deprecated to allow for a gradual transition). Instead there is: (1) getTypeSizeInBits - a number of bits that suffices to hold all values of the type. For a primitive type, this is the minimum number of bits. For an i36 this is 36 bits. For x86 long double it is 80. This corresponds to gcc's TYPE_PRECISION. (2) getTypeStoreSizeInBits - the maximum number of bits that is written when storing the type (or read when reading it). For an i36 this is 40 bits, for an x86 long double it is 80 bits. This is the size alias analysis is interested in (getTypeStoreSize returns the number of bytes). There doesn't seem to be anything corresponding to this in gcc. (3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded up to a multiple of the alignment. For an i36 this is 64, for an x86 long double this is 96 or 128 depending on the OS. This is the spacing between consecutive elements when you form an array out of this type (getABITypeSize returns the number of bytes). This is TYPE_SIZE in gcc. Since successive elements in a SequentialType (arrays, pointers and vectors) need to be aligned, the spacing between them will be given by getABITypeSize. This means that the size of an array is the length times the getABITypeSize. It also means that GEP computations need to use getABITypeSize when computing offsets. Furthermore, if an alloca allocates several elements at once then these too need to be aligned, so the size of the alloca has to be the number of elements multiplied by getABITypeSize. Logically speaking this doesn't have to be the case when allocating just one element, but it is simpler to also use getABITypeSize in this case. So alloca's and mallocs should use getABITypeSize. Finally, since gcc's only notion of size is that given by getABITypeSize, if you want to output assembler etc the same as gcc then getABITypeSize is the size you want. Since a store will overwrite no more than getTypeStoreSize bytes, and a read will read no more than that many bytes, this is the notion of size appropriate for alias analysis calculations. In this patch I have corrected all type size uses except some of those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard cases). I will get around to auditing these too at some point, but I could do with some help. Finally, I made one change which I think wise but others might consider pointless and suboptimal: in an unpacked struct the amount of space allocated for a field is now given by the ABI size rather than getTypeStoreSize. I did this because every other place that reserves memory for a type (eg: alloca) now uses getABITypeSize, and I didn't want to make an exception for unpacked structs, i.e. I did it to make things more uniform. This only effects structs containing long doubles and arbitrary precision integers. If someone wants to pack these types more tightly they can always use a packed struct. llvm-svn: 43620
* Make i64=expand_vector_elt(v2i64) work in 32-bit mode.Dale Johannesen2007-10-311-0/+5
| | | | llvm-svn: 43535
* The guaranteed alignment of ptr+offset is only the minimum ofDuncan Sands2007-10-281-10/+9
| | | | | | | | | | | | | | | | | | | of offset and the alignment of ptr if these are both powers of 2. While the ptr alignment is guaranteed to be a power of 2, there is no reason to think that offset is. For example, if offset is 12 (the size of a long double on x86-32 linux) and the alignment of ptr is 8, then the alignment of ptr+offset will in general be 4, not 8. Introduce a function MinAlign, lifted from gcc, for computing the minimum guaranteed alignment. I've tried to fix up everywhere under lib/CodeGen/SelectionDAG/. I also changed some places that weren't wrong (because both values were a power of 2), as a defensive change against people copying and pasting the code. Hopefully someone who cares about alignment will review the rest of LLVM and fix up the remaining places. Since I'm on x86 I'm not very motivated to do this myself... llvm-svn: 43421
* Another expansion for i64 multiply, suitable for PPC.Dale Johannesen2007-10-241-0/+9
| | | | llvm-svn: 43314
* Fix a few places vector operations were not gettingDale Johannesen2007-10-201-6/+9
| | | | | | the operand's type from the right place. llvm-svn: 43195
* Redo "last ppc long double fix" as Chris wants.Dale Johannesen2007-10-191-1/+2
| | | | llvm-svn: 43189
* Fix a really nasty vector miscompilation bill recently introduced.Chris Lattner2007-10-191-2/+2
| | | | llvm-svn: 43181
* Add support for byval function whose argument is not 32 bit aligned.Rafael Espindola2007-10-191-2/+15
| | | | | | | | | | To do this it is necessary to add a "always inline" argument to the memcpy node. For completeness I have also added this node to memmove and memset. I have also added getMem* functions, because the extra argument makes it cumbersome to use getNode and because I get confused by it :-) llvm-svn: 43172
* Negative indices aren't allowed here.Bill Wendling2007-10-191-1/+1
| | | | llvm-svn: 43161
* Pointer arithmetic should be done with the index the same size as the pointer.Bill Wendling2007-10-181-0/+7
| | | | llvm-svn: 43120
* Add support for ISD::SELECT in SplitVectorOp.Dan Gohman2007-10-171-0/+20
| | | | llvm-svn: 43072
* Return Expand from getOperationAction for all extendedDuncan Sands2007-10-171-2/+2
| | | | | | | | | | | | | | | | | | | types. This is needed for SIGN_EXTEND_INREG at least. It is not clear if this is correct for other operations. On the other hand, for the various load/store actions it seems to correct to return the type action, as is currently done. Also, it seems that SelectionDAG::getValueType can be called for extended value types; introduce a map for holding these, since we don't really want to extend the vector to be 2^32 pointers long! Generalize DAGTypeLegalizer::PromoteResult_TRUNCATE and DAGTypeLegalizer::PromoteResult_INT_EXTEND to handle the various funky possibilities that apints introduce, for example that you can promote to a type that needs to be expanded. llvm-svn: 43071
* Fixes due to lack of type-safety for ValueType: (1) ValueTypeDuncan Sands2007-10-161-3/+3
| | | | | | | being passed instead of an opcode; (2) ValueType being passed for isVolatile (!) in getLoad. llvm-svn: 43028
* Move CreateStackTemporary out to SelectionDAGChris Lattner2007-10-151-20/+7
| | | | llvm-svn: 42995
* One xform performed by LegalizeDAG is transformation of "store of fp" to ↵Chris Lattner2007-10-151-6/+28
| | | | | | | | | | | | | "store of int". Make two changes: 1) only xform "store of f32" if i32 is a legal type for the target. 2) only xform "store of f64" if either i64 or i32 are legal for the target. 3) if i64 isn't legal, manually lower to 2 stores of i32 instead of letting a later pass of legalize do it. This is ugly, but helps future changes I'm about to commit. llvm-svn: 42980
* remove misleading comment.Chris Lattner2007-10-141-2/+1
| | | | llvm-svn: 42970
* If a target doesn't have HasMULHU or HasUMUL_LOHI, ExpandOp would returnChris Lattner2007-10-141-1/+0
| | | | | | without lo/hi set. Fall through to making a libcall instead. llvm-svn: 42969
* Add a simple optimization to simplify the input toChris Lattner2007-10-131-1/+1
| | | | | | | truncate and truncstore instructions, based on the knowledge that they don't demand the top bits. llvm-svn: 42952
* ppc long double. Implement fabs and fneg.Dale Johannesen2007-10-121-0/+16
| | | | llvm-svn: 42924
* Implement i64->ppcf128 conversions.Dale Johannesen2007-10-121-1/+20
| | | | llvm-svn: 42919
* Add support to SplitVectorOp for powi, where the second operandDan Gohman2007-10-121-0/+6
| | | | | | is a scalar integer. llvm-svn: 42906
* PPC long double. Implement a couple more conversions.Dale Johannesen2007-10-121-0/+35
| | | | llvm-svn: 42888
* Codegen support for vector intrinsics.Dan Gohman2007-10-111-27/+114
| | | | | | | | | | | | Factor out the code that expands the "nasty scalar code" for unrolling vectors into a separate routine, teach it how to handle mixed vector/scalar operands, as seen in powi, and use it for several operators, including sin, cos, powi, and pow. Add support in SplitVectorOp for fpow, fpowi and for several unary operators. llvm-svn: 42884
* Implement ppc long double->uint conversion.Dale Johannesen2007-10-111-3/+25
| | | | | | Make ppc long double constants print. llvm-svn: 42882
* Next PPC long double bits. First cut at constants.Dale Johannesen2007-10-111-0/+8
| | | | | | | | | No compile-time support for constant operations yet, just format transformations. Make readers and writers work. Split constants into 2 doubles in Legalize. llvm-svn: 42865
OpenPOWER on IntegriCloud