summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG
Commit message (Collapse)AuthorAgeFilesLines
...
* Implement split and scalarize for SELECT_CC, fixing PR2504Chris Lattner2008-06-301-0/+23
| | | | llvm-svn: 52887
* Revert (52748 and friends):Anton Korobeynikov2008-06-291-7/+13
| | | | | | | | | | | | Move GetConstantStringInfo to lib/Analysis. Remove string output routine from Constant. Update all callers. Change debug intrinsic api slightly to accomodate move of routine, these now return values instead of strings. This unbreaks llvm-gcc bootstrap. llvm-svn: 52884
* Really fix the bootstrap failure.Chris Lattner2008-06-281-9/+5
| | | | llvm-svn: 52854
* Add back the capability to include nul characters in strings with Chris Lattner2008-06-281-1/+1
| | | | | | | GetConstantStringInfo. This will hopefully restore llvm-gcc to happy bootstrap land. llvm-svn: 52851
* When folding a bitcast into a load or store, preserve the alignmentDan Gohman2008-06-281-2/+2
| | | | | | | information of the original load or store, which is checked to be at least as good, and possibly better. llvm-svn: 52849
* simplify this check, GetConstantStringInfo validates that aChris Lattner2008-06-271-5/+3
| | | | | | global is constant already. No functionality change. llvm-svn: 52812
* Refactor the DebugInfoDesc stuff out of the MachineModuleInfo file. Clean upBill Wendling2008-06-271-0/+1
| | | | | | some uses of std::vector, where it's return std::vector by value. Yuck! llvm-svn: 52800
* duncan points out that isOperationLegal includes a check forChris Lattner2008-06-261-2/+2
| | | | | | type legality. Thanks Duncan! llvm-svn: 52786
* Move GetConstantStringInfo to lib/Analysis. RemoveEric Christopher2008-06-261-2/+2
| | | | | | | | | string output routine from Constant. Update all callers. Change debug intrinsic api slightly to accomodate move of routine, these now return values instead of strings. llvm-svn: 52748
* when we know the signbit of an input to uint_to_fp is zero,Chris Lattner2008-06-261-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | change it to sint_to_fp on targets where that is cheaper (and visaversa of course). This allows us to compile uint_to_fp to: _test: movl 4(%esp), %eax shrl $23, %eax cvtsi2ss %eax, %xmm0 movl 8(%esp), %eax movss %xmm0, (%eax) ret instead of: .align 3 LCPI1_0: ## double .long 0 ## double least significant word 4.5036e+15 .long 1127219200 ## double most significant word 4.5036e+15 .text .align 4,0x90 .globl _test _test: subl $12, %esp movl 16(%esp), %eax shrl $23, %eax movl %eax, (%esp) movl $1127219200, 4(%esp) movsd (%esp), %xmm0 subsd LCPI1_0, %xmm0 cvtsd2ss %xmm0, %xmm0 movl 20(%esp), %eax movss %xmm0, (%eax) addl $12, %esp ret llvm-svn: 52747
* - Fix a x86 vector isel bug: illegal transformation of a vector_shuffle into aEvan Cheng2008-06-251-11/+11
| | | | | | | | shift. - Add a readme entry for a missing vector_shuffle optimization that results in awful codegen. llvm-svn: 52740
* Add support for expanding PPC 128 bit floats.Duncan Sands2008-06-254-9/+215
| | | | | | | | | | | | | | | | | | | | For this it is convenient to permit floats to be used with EXTRACT_ELEMENT, so I tweaked things to allow that. I also added libcalls for ppcf128 to i32 forms of FP_TO_XINT, since they exist in libgcc and this case can certainly occur (and does occur in the testsuite) - before the i64 libcall was being used. Also, the XINT_TO_FP result seemed to be wrong when the argument is an i128: the wrong fudge factor was added (the i32 and i64 cases were handled directly, but the i128 code fell through to some generic softening code which seemed to think it was i64 to f32!). So I fixed it by adding a fudge factor that I found in my breakfast cereal. llvm-svn: 52739
* Add/complete support for integer and floatDuncan Sands2008-06-253-38/+282
| | | | | | | | select_cc and friends. This code could be factorized a bit but I'm not sure that it's worth it. llvm-svn: 52724
* Remove the OrigVT member from AtomicSDNode, as it is redundant withDan Gohman2008-06-253-13/+9
| | | | | | the base SDNode's VTList. llvm-svn: 52722
* Added MemOperands to Atomic operations since Atomics touches memory.Mon P Wang2008-06-253-34/+93
| | | | | | | | Added abstract class MemSDNode for any Node that have an associated MemOperand Changed atomic.lcs => atomic.cmp.swap, atomic.las => atomic.load.add, and atomic.lss => atomic.load.sub llvm-svn: 52706
* Use the new PriorityQueue in ScheduleDAGList too, which alsoDan Gohman2008-06-231-19/+3
| | | | | | needs arbitrary-element removal. llvm-svn: 52654
* Move a DenseMap's declaration outside of a loop, and just callDan Gohman2008-06-231-1/+2
| | | | | | | clear() on each iteration. This avoids allocating and deallocating all of DenseMap's memory on each iteration. llvm-svn: 52642
* Duncan pointed out this code could be tidied.Dan Gohman2008-06-231-6/+3
| | | | llvm-svn: 52624
* Port some integer multiplication fixes from LegalizeDAG.Duncan Sands2008-06-231-8/+24
| | | | | | | Bail out with an error if there is no libcall available for the given size of integer. llvm-svn: 52622
* Support for expanding the result of EXTRACT_ELEMENT.Duncan Sands2008-06-234-7/+24
| | | | llvm-svn: 52621
* Cleanup up LegalizeTypes handling of loads andDuncan Sands2008-06-235-24/+22
| | | | | | stores. llvm-svn: 52620
* Make custom lowering of ADD work correctly. ThisDuncan Sands2008-06-221-3/+3
| | | | | | | | | | fixes PR2476; patch by Richard Osborne. The same problem exists for a bunch of other operators, but I'm ignoring this because they will be automagically fixed when the new LegalizeTypes infrastructure lands, since it already solves this problem centrally. llvm-svn: 52610
* Simplify some getNode calls.Dan Gohman2008-06-211-6/+3
| | | | llvm-svn: 52604
* canClobberPhysRegDefs shouldn't called without checking hasPhysRegDefs;Dan Gohman2008-06-211-3/+2
| | | | | | check this with an assert. llvm-svn: 52603
* Use clear() to zero an existing APInt.Dan Gohman2008-06-211-1/+1
| | | | llvm-svn: 52601
* Remove a redundant return.Dan Gohman2008-06-211-2/+0
| | | | llvm-svn: 52585
* Remove ScheduleDAG's SUnitMap altogether. Instead, use SDNode's NodeIdDan Gohman2008-06-214-50/+38
| | | | | | | field, which is otherwise unused after instruction selection, as an index into the SUnit array. llvm-svn: 52583
* Add a priority queue class, which is a wrapper around std::priority_queueDan Gohman2008-06-212-11/+8
| | | | | | | and provides fairly efficient removal of arbitrary elements. Switch ScheduleDAGRRList from std::set to this new priority queue. llvm-svn: 52582
* Support for load/store of expanded float types. IDuncan Sands2008-06-213-1/+65
| | | | | | | don't know if a truncating store is possible here, but added support for it anyway. llvm-svn: 52577
* Change ScheduleDAG's SUnitMap from DenseMap<SDNode*, vector<SUnit*> >Dan Gohman2008-06-214-34/+46
| | | | | | | | to DenseMap<SDNode*, SUnit*>, and adjust the way cloned SUnit nodes are handled so that only the original node needs to be in the map. This speeds up llc on 447.dealII.llvm.bc by about 2%. llvm-svn: 52576
* Simplify some template parameterization.Dan Gohman2008-06-211-19/+12
| | | | llvm-svn: 52571
* Share some code that is common between integer andDuncan Sands2008-06-206-412/+560
| | | | | | float expansion (and sometimes vector splitting too). llvm-svn: 52548
* Rename the operation of turning a float type into anDuncan Sands2008-06-205-77/+76
| | | | | | | | | integer of the same type. Before it was "promotion", but this is confusing because it is quite different to promotion of integers. Call it "softening" instead, inspired by "soft float". llvm-svn: 52546
* Clean up some uses of std::distance, now that we have allnodes_size.Dan Gohman2008-06-202-4/+3
| | | | llvm-svn: 52545
* Teach ReturnInst lowering about aggregate return values.Dan Gohman2008-06-201-22/+28
| | | | llvm-svn: 52522
* Fix the index calculations for the extractvalue lowering code.Dan Gohman2008-06-201-2/+2
| | | | llvm-svn: 52517
* Simplify the ComputeLinearIndex logic and fix a few bugs.Dan Gohman2008-06-201-16/+10
| | | | llvm-svn: 52516
* ISD::UNDEF should be expanded recursively / iteratively.Evan Cheng2008-06-191-1/+0
| | | | llvm-svn: 52508
* Split type expansion into ExpandInteger and ExpandFloatDuncan Sands2008-06-177-1500/+1611
| | | | | | | | rather than bundling them together. Rename FloatToInt to PromoteFloat (better, if not perfect). Reorganize files by types rather than by operations. llvm-svn: 52408
* add a new -enable-value-prop flag for llcbeta, that enables propagationChris Lattner2008-06-171-12/+132
| | | | | | | | | | | of value info (sign/zero ext info) from one MBB to another. This doesn't handle much right now because of two limitations: 1) only handles zext/sext, not random bit propagation (no assert exists for this) 2) doesn't handle phis. llvm-svn: 52383
* Fix spelling.Duncan Sands2008-06-171-1/+1
| | | | llvm-svn: 52381
* Allow these transforms for types like i256 whileDuncan Sands2008-06-161-8/+6
| | | | | | | | still excluding types like i1 (not byte sized) and i120 (loading an i120 requires loading an i64, an i32, an i16 and an i8, which is expensive). llvm-svn: 52310
* The transforms in visitEXTRACT_VECTOR_ELT areDuncan Sands2008-06-151-4/+4
| | | | | | | | not valid if the load is volatile. Hopefully all wrong DAG combiner transforms of volatile loads and stores have now been caught. llvm-svn: 52293
* LegalizeTypes support for INSERT_VECTOR_ELT withDuncan Sands2008-06-153-26/+59
| | | | | | a non-constant index. llvm-svn: 52292
* Remove a redundant AfterLegalize check. TurnDuncan Sands2008-06-141-4/+5
| | | | | | | | on some code when !AfterLegalize - but since this whole code section is turned off by an "if (0)" it's not really turning anything on. llvm-svn: 52276
* add missing atomic intrinsic from gccAndrew Lenharth2008-06-143-0/+6
| | | | llvm-svn: 52270
* Disable some DAG combiner optimizations that may beDuncan Sands2008-06-132-59/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wrong for volatile loads and stores. In fact this is almost all of them! There are three types of problems: (1) it is wrong to change the width of a volatile memory access. These may be used to do memory mapped i/o, in which case a load can have an effect even if the result is not used. Consider loading an i32 but only using the lower 8 bits. It is wrong to change this into a load of an i8, because you are no longer tickling the other three bytes. It is also unwise to make a load/store wider. For example, changing an i16 load into an i32 load is wrong no matter how aligned things are, since the fact of loading an additional 2 bytes can have i/o side-effects. (2) it is wrong to change the number of volatile load/stores: they may be counted by the hardware. (3) it is wrong to change a volatile load/store that requires one memory access into one that requires several. For example on x86-32, you can store a double in one processor operation, but to store an i64 requires two (two i32 stores). In a multi-threaded program you may want to bitcast an i64 to a double and store as a double because that will occur atomically, and be indivisible to other threads. So it would be wrong to convert the store-of-double into a store of an i64, because this will become two i32 stores - no longer atomic. My policy here is to say that the number of processor operations for an illegal operation is undefined. So it is alright to change a store of an i64 (requires at least two stores; but could be validly lowered to memcpy for example) into a store of double (one processor op). In short, if the new store is legal and has the same size then I say that the transform is ok. It would also be possible to say that transforms are always ok if before they were illegal, whether after they are illegal or not, but that's more awkward to do and I doubt it buys us anything much. However this exposed an interesting thing - on x86-32 a store of i64 is considered legal! That is because operations are marked legal by default, regardless of whether the type is legal or not. In some ways this is clever: before type legalization this means that operations on illegal types are considered legal; after type legalization there are no illegal types so now operations are only legal if they really are. But I consider this to be too cunning for mere mortals. Better to do things explicitly by testing AfterLegalize. So I have changed things so that operations with illegal types are considered illegal - indeed they can never map to a machine operation. However this means that the DAG combiner is more conservative because before it was "accidentally" performing transforms where the type was illegal because the operation was nonetheless marked legal. So in a few such places I added a check on AfterLegalize, which I suppose was actually just forgotten before. This causes the DAG combiner to do slightly more than it used to, which resulted in the X86 backend blowing up because it got a slightly surprising node it wasn't expecting, so I tweaked it. llvm-svn: 52254
* Sometimes (rarely) nodes held in LegalizeTypesDuncan Sands2008-06-114-68/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | maps can be deleted. This happens when RAUW replaces a node N with another equivalent node E, deleting the first node. Solve this by adding (N, E) to ReplacedNodes, which is already used to remap nodes to replacements. This means that deleted nodes are being allowed in maps, which can be delicate: the memory may be reused for a new node which might get confused with the old deleted node pointer hanging around in the maps, so detect this and flush out maps if it occurs (ExpungeNode). The expunging operation is expensive, however it never occurs during a llvm-gcc bootstrap or anywhere in the nightly testsuite. It occurs three times in "make check": Alpha/illegal-element-type.ll, PowerPC/illegal-element-type.ll and X86/mmx-shift.ll. If expunging proves to be too expensive then there are other more complicated ways of solving the problem. In the normal case this patch adds the overhead of a few more map lookups, which is hopefully negligable. llvm-svn: 52214
* Teach isGAPlusOffset to respect a GlobalAddressSDNode's offsetDan Gohman2008-06-091-1/+3
| | | | | | value, which is something that apparently isn't used much. llvm-svn: 52158
* CodeGen support for aggregate-value function arguments.Dan Gohman2008-06-091-112/+139
| | | | llvm-svn: 52156
OpenPOWER on IntegriCloud