aboutsummaryrefslogtreecommitdiff
path: root/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
AgeCommit message (Collapse)Author
2008-01-31Rename ISD::FLT_ROUNDS to ISD::FLT_ROUNDS_ to avoid conflictingDan Gohman
with the real FLT_ROUNDS (defined in <float.h>). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46587 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-31Create a new class, MemOperand, for describing memory referencesDan Gohman
in the backend. Introduce a new SDNode type, MemOperandSDNode, for holding a MemOperand in the SelectionDAG IR, and add a MemOperand list to MachineInstr, and code to manage them. Remove the offset field from SrcValueSDNode; uses of SrcValueSDNode that were using it are all all using MemOperandSDNode now. Also, begin updating some getLoad and getStore calls to use the PseudoSourceValue objects. Most of this was written by Florian Brander, some reorganization and updating to TOT by me. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46585 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-30Factor the addressing mode and the load/store VT out of LoadSDNodeDan Gohman
and StoreSDNode into their common base class LSBaseSDNode. Member functions getLoadedVT and getStoredVT are replaced with the common getMemoryVT to simplify code that will handle both loads and stores. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46538 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-29Properly expand extract-element for non-power-of-2 codegenNate Begeman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46486 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-23The last pieces needed for loading arbitraryDuncan Sands
precision integers. This won't actually work (and most of the code is dead) unless the new legalization machinery is turned on. While there, I rationalized the handling of i1, and removed some bogus (and unused) sextload patterns. For i1, this could result in microscopically better code for some architectures (not X86). It might also result in worse code if annotating with AssertZExt nodes turns out to be more harmful than helpful. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46280 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-22The final piece needed for storing arbitrary precisionDuncan Sands
integers. Handle truncstore of a legal type to an unusual number of bits. Most of this code is not reachable unless the new legalize infrastructure is turned on. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46249 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-20Do not generate a FP_ROUND of f64 to f64.Dale Johannesen
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46195 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-17This commit changes:Chris Lattner
1. Legalize now always promotes truncstore of i1 to i8. 2. Remove patterns and gunk related to truncstore i1 from targets. 3. Rename the StoreXAction stuff to TruncStoreAction in TLI. 4. Make the TLI TruncStoreAction table a 2d table to handle from/to conversions. 5. Mark a wide variety of invalid truncstores as such in various targets, e.g. X86 currently doesn't support truncstore of any of its integer types. 6. Add legalize support for truncstores with invalid value input types. 7. Add a dag combine transform to turn store(truncate) into truncstore when safe. The later allows us to compile CodeGen/X86/storetrunc-fp.ll to: _foo: fldt 20(%esp) fldt 4(%esp) faddp %st(1) movl 36(%esp), %eax fstps (%eax) ret instead of: _foo: subl $4, %esp fldt 24(%esp) fldt 8(%esp) faddp %st(1) fstps (%esp) movl 40(%esp), %eax movss (%esp), %xmm0 movss %xmm0, (%eax) addl $4, %esp ret git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46140 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-17* Introduce a new SelectionDAG::getIntPtrConstant methodChris Lattner
and switch various codegen pieces and the X86 backend over to using it. * Add some comments to SelectionDAGNodes.h * Introduce a second argument to FP_ROUND, which indicates whether the FP_ROUND changes the value of its input. If not it is safe to xform things like fp_extend(fp_round(x)) -> x. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46125 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-16merge a few pieces of code that do the store/load to stack Chris Lattner
pattern to use EmitStackConvert now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46066 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-16rename ExpandBIT_CONVERT to EmitStackConvert, generalizing Chris Lattner
it to allow it to emit different load and store kinds. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46065 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-16simplify a bunch of code by using SelectionDAG::CreateStackTemporary Chris Lattner
instead of inlining its body. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46062 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-16Change legalizeop of FP_ROUND and FP_EXTEND to not fall throughChris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46061 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-15The type of the 'abort' node should be pointer type (becauseChris Lattner
it's a function pointer) not MVT::Other. This fixes builtin_trap lowering on ppc, alpha, ia64 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46018 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-15Add support for targets that have a legal ISD::TRAP.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46014 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-15For PR1839: add initial support for __builtin_trap. llvm-gcc part is missedAnton Korobeynikov
as well as PPC codegen git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46001 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-10Output sinl for a long double FSIN node, not sin.Duncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45833 91177308-0d34-0410-b5e6-96231b3b80d8
2008-01-05If custom lowering of insert element fails, the result Val will be 0.Nate Begeman
Don't overwrite a variable used by the fallthrough code path in this case. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45630 91177308-0d34-0410-b5e6-96231b3b80d8
2007-12-31Fix PR1833 - eh.exception and eh.selector return twoDuncan Sands
values, which means doing extra legalization work. It would be easier to get this kind of thing right if there was some documentation... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45472 91177308-0d34-0410-b5e6-96231b3b80d8
2007-12-31Rename SSARegMap -> MachineRegisterInfo in keeping with the idea Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45467 91177308-0d34-0410-b5e6-96231b3b80d8
2007-12-29Remove attribution from file headers, per discussion on llvmdev.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45418 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-24Implement expand support for MERGE_VALUEs that only produces one result.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44304 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-24Several changes:Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44300 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-19ExpandUnalignedLoad doesn't handle vectors right at all apparently.Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44243 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-19Implement vector expand support for shuffle_vector. This fixes PR1811.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44242 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-19Implement splitting of UNDEF nodes. This is the first step towards fixing PR1811Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44239 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-19Add support in SplitVectorOp for remainder operators.Dan Gohman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44233 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-17Add support for vectors to int <-> float casts.Nate Begeman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44204 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-15Implement necessary bits for flt_rounds gcc builtin. Anton Korobeynikov
Codegen bits and llvm-gcc support will follow. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44182 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-15Basic non-power-of-2 vector supportNate Begeman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44181 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-13Unify CALLSEQ_{START,END}. They take 4 parameters: the chain, two stackBill Wendling
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... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44037 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-09Move MinAlign to MathExtras.h.Duncan Sands
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43944 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-09Much improved pic jumptable codegen:Evan Cheng
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43924 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-09Didn't mean to check these in.Evan Cheng
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43923 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-09Bug fix. Passive nodes are not in SUnitMap.Evan Cheng
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43922 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-06Remainder operations must be either integer or floating-point.Dan Gohman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43781 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-05Add support for vector remainder operations.Dan Gohman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43744 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-01Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.Duncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-31Make i64=expand_vector_elt(v2i64) work in 32-bit mode.Dale Johannesen
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43535 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-28The guaranteed alignment of ptr+offset is only the minimum ofDuncan Sands
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... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43421 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-24Another expansion for i64 multiply, suitable for PPC.Dale Johannesen
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43314 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-20Fix a few places vector operations were not gettingDale Johannesen
the operand's type from the right place. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43195 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-19Redo "last ppc long double fix" as Chris wants.Dale Johannesen
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43189 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-19Fix a really nasty vector miscompilation bill recently introduced.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43181 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-19Add support for byval function whose argument is not 32 bit aligned.Rafael Espindola
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 :-) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43172 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-19Negative indices aren't allowed here.Bill Wendling
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43161 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-18Pointer arithmetic should be done with the index the same size as the pointer.Bill Wendling
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43120 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-17Add support for ISD::SELECT in SplitVectorOp.Dan Gohman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43072 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-17Return Expand from getOperationAction for all extendedDuncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43071 91177308-0d34-0410-b5e6-96231b3b80d8
2007-10-16Fixes due to lack of type-safety for ValueType: (1) ValueTypeDuncan Sands
being passed instead of an opcode; (2) ValueType being passed for isVolatile (!) in getLoad. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43028 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-10-01 23:04:22 +0000