summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Don't produce invalid comparisons after legalize.Chris Lattner2008-10-281-2/+4
| | | | llvm-svn: 58320
* Use a legal integer type for vector shuffle maskDuncan Sands2008-10-191-4/+4
| | | | | | | | | elements. Otherwise LegalizeTypes will, reasonably enough, legalize the mask, which may result in it no longer being a BUILD_VECTOR node (LegalizeDAG simply ignores the legality or not of vector masks). llvm-svn: 57782
* Teach DAGCombine to fold constant offsets into GlobalAddress nodes,Dan Gohman2008-10-181-0/+22
| | | | | | | | | | | | | | | | | | | | | | and add a TargetLowering hook for it to use to determine when this is legal (i.e. not in PIC mode, etc.) This allows instruction selection to emit folded constant offsets in more cases, such as the included testcase, eliminating the need for explicit arithmetic instructions. This eliminates the need for the C++ code in X86ISelDAGToDAG.cpp that attempted to achieve the same effect, but wasn't as effective. Also, fix handling of offsets in GlobalAddressSDNodes in several places, including changing GlobalAddressSDNode's offset from int to int64_t. The Mips, Alpha, Sparc, and CellSPU targets appear to be unaware of GlobalAddress offsets currently, so set the hook to false on those targets. llvm-svn: 57748
* Define patterns for shld and shrd that match immediateDan Gohman2008-10-171-5/+9
| | | | | | | | | | | | | | | | | | shift counts, and patterns that match dynamic shift counts when the subtract is obscured by a truncate node. Add DAGCombiner support for recognizing rotate patterns when the shift counts are defined by truncate nodes. Fix and simplify the code for commuting shld and shrd instructions to work even when the given instruction doesn't have a parent, and when the caller needs a new instruction. These changes allow LLVM to use the shld, shrd, rol, and ror instructions on x86 to replace equivalent code using two shifts and an or in many more cases. llvm-svn: 57662
* Rename LoadX to LoadExt.Evan Cheng2008-10-141-12/+12
| | | | llvm-svn: 57526
* Rename APFloat::convertToAPInt to bitcastToAPInt toDale Johannesen2008-10-091-3/+3
| | | | | | | make it clearer what the function does. No functional change. llvm-svn: 57325
* Rename ConstantSDNode's getSignExtended to getSExtValue, forDan Gohman2008-09-261-7/+7
| | | | | | | consistancy with ConstantInt, and re-implement it in terms of ConstantInt's getSExtValue. llvm-svn: 56700
* Reapplying r56550Bill Wendling2008-09-241-13/+13
| | | | llvm-svn: 56553
* Temporarily revert r56550 until missing commit can be added.Eric Christopher2008-09-241-13/+13
| | | | llvm-svn: 56551
* Refactor the constant folding code into it's own function. And call it from bothBill Wendling2008-09-241-13/+13
| | | | | | | | | | the SelectionDAG and DAGCombiner code. The only functionality change is that now the DAG combiner is performing the constant folding for these operations instead of being a no-op. This is *not* in response to a bug, so there isn't a testcase. llvm-svn: 56550
* Per review feedback: Only performEvan Cheng2008-09-221-39/+27
| | | | | | | (srl x, (trunc (and y, c))) -> (srl x, (and (trunc y), c)) etc. when both "trunc" and "and" have single uses. llvm-svn: 56452
* Change ConstantSDNode and ConstantFPSDNode to use ConstantInt* andDan Gohman2008-09-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | ConstantFP* instead of APInt and APFloat directly. This reduces the amount of time to create ConstantSDNode and ConstantFPSDNode nodes when ConstantInt* and ConstantFP* respectively are already available, as is the case in SelectionDAGBuild.cpp. Also, it reduces the amount of time to legalize constants into constant pools, and the amount of time to add ConstantFP operands to MachineInstrs, due to eliminating ConstantInt::get and ConstantFP::get calls. It increases the amount of work needed to create new constants in cases where the client doesn't already have a ConstantInt* or ConstantFP*, such as legalize expanding 64-bit integer constants to 32-bit constants. And it adds a layer of indirection for the accessor methods. But these appear to be outweight by the benefits in most cases. It will also make it easier to make ConstantSDNode and ConstantFPNode more consistent with ConstantInt and ConstantFP. llvm-svn: 56162
* Rename ConstantSDNode::getValue to getZExtValue, for consistencyDan Gohman2008-09-121-41/+48
| | | | | | | with ConstantInt. This led to fixing a bug in TargetLowering.cpp using getValue instead of getAPIntValue. llvm-svn: 56159
* In visitUREM, arrange for the temporary UDIV node to beDan Gohman2008-09-081-0/+1
| | | | | | revisited, consistent with the code in visitSREM. llvm-svn: 55923
* Revert my previous change -- the subtraction of two constants was a no-opBill Wendling2008-09-081-1/+1
| | | | | | | | | before. This is taken care of in the selection DAG pass. In my opinion, this should be in one place or the other. I.e., it should probably be removed from the DAG combiner (along with the other arithmetic transformations on constants that are essentially no-ops). llvm-svn: 55889
* ConvertBill Wendling2008-09-071-1/+1
| | | | | | | | // fold (sub c1, c2) -> c1-c2 from a no-op into an actual transformation. llvm-svn: 55886
* Fix a search+replace-o.Dan Gohman2008-09-051-1/+1
| | | | llvm-svn: 55824
* Clean up uses of TargetLowering::getTargetMachine.Dan Gohman2008-09-041-4/+4
| | | | llvm-svn: 55769
* Another situation where ROTR is cheaper than ROTL.Bill Wendling2008-08-311-3/+3
| | | | llvm-svn: 55577
* For this pattern, ROTR is the cheaper option.Bill Wendling2008-08-311-4/+4
| | | | llvm-svn: 55576
* - Fix comment so that it describes how the code really works:Bill Wendling2008-08-311-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | // fold (or (shl x, (*ext y)), (srl x, (*ext (sub 32, y)))) -> // (rotl x, y) // fold (or (shl x, (*ext y)), (srl x, (*ext (sub 32, y)))) -> // (rotr x, (sub 32, y)) Example: (x == 0xDEADBEEF and y == 4) (x << 4) | (x >> 28) => 0xEADBEEF0 | 0x0000000D => 0xEADBEEFD (rotl x, 4) => 0xEADBEEFD (rotr x, 28) => 0xEADBEEFD - Fix comment and code for second version. It wasn't using the rot* propertly. // fold (or (shl x, (*ext (sub 32, y))), (srl x, (*ext r))) -> // (rotr x, y) // fold (or (shl x, (*ext (sub 32, y))), (srl x, (*ext r))) -> // (rotl x, (sub 32, y)) (x << 28) | (x >> 4) => 0xD0000000 | 0x0DEADBEE => 0xDDEADBEE (rotl x, 4) => 0xEADBEEFD (rotr x, 28) => (0xEADBEEFD) llvm-svn: 55575
* fix some 80-col violationsGabor Greif2008-08-301-19/+23
| | | | llvm-svn: 55571
* Transform (x << (y&31)) -> (x << y). This takes advantage of the fact x86 ↵Evan Cheng2008-08-301-0/+60
| | | | | | shift instructions 2nd operand (shift count) is limited to 0 to 31 (or 63 in the x86-64 case). llvm-svn: 55558
* Fix 80 col. violations.Evan Cheng2008-08-291-2/+4
| | | | llvm-svn: 55551
* Back out 55498. It broken Apple style bootstrapping.Evan Cheng2008-08-291-106/+81
| | | | llvm-svn: 55549
* erect abstraction boundaries for accessing SDValue members, rename Val -> ↵Gabor Greif2008-08-281-299/+299
| | | | | | Node to reflect semantics llvm-svn: 55504
* Optimize DAGCombiner's worklist processing. Previously it startedDan Gohman2008-08-281-77/+102
| | | | | | | | | | | | | its work by putting all nodes in the worklist, requiring a big dynamic allocation. Now, DAGCombiner just iterates over the AllNodes list and maintains a worklist for nodes that are newly created or need to be revisited. This allows the worklist to stay small in most cases, so it can be a SmallVector. This has the side effect of making DAGCombine not miss a folding opportunity in alloca-align-rounding.ll. llvm-svn: 55498
* disallow direct access to SDValue::ResNo, provide a getter insteadGabor Greif2008-08-261-2/+2
| | | | llvm-svn: 55394
* Disable DAGCombine's alignment inference in "fast" codegen mode.Dan Gohman2008-08-201-5/+8
| | | | llvm-svn: 55059
* Improve support for vector casts in LLVM IR and CodeGen.Dan Gohman2008-08-141-0/+4
| | | | llvm-svn: 54784
* Take the FrameOffset into account when computing the alignmentDan Gohman2008-08-111-1/+1
| | | | | | of stack objects. This fixes PR2656. llvm-svn: 54646
* Improve dagcombining for sext-loads and sext-in-reg nodes.Dan Gohman2008-07-311-9/+21
| | | | llvm-svn: 54239
* Rename SDOperand to SDValue.Dan Gohman2008-07-271-701/+701
| | | | llvm-svn: 54128
* Tidy SDNode::use_iterator, and complete the transition to have itDan Gohman2008-07-271-8/+8
| | | | | | | parallel its analogue, Value::value_use_iterator. The operator* method now returns the user, rather than the use. llvm-svn: 54127
* Fix pr2566: incorrect assumption about bit_convert. It doesn't not have to ↵Evan Cheng2008-07-221-1/+2
| | | | | | output a vector value. Patch by Nicolas Capens! llvm-svn: 53932
* Add titles to the various SelectionDAG viewGraph callsDan Gohman2008-07-211-18/+0
| | | | | | | that include useful information like the name of the block being viewed and the current phase of compilation. llvm-svn: 53872
* Add VerifyNode, a place to put sanity checks onDuncan Sands2008-07-211-1/+2
| | | | | | | | | | | | generic SDNode's (nodes with their own constructors should do sanity checking in the constructor). Add sanity checks for BUILD_VECTOR and fix all the places that were producing bogus BUILD_VECTORs, as found by "make check". My favorite is the BUILD_VECTOR with only two operands that was being used to build a vector with four elements! llvm-svn: 53850
* Revert 53729, after waking up in the middle ofDuncan Sands2008-07-181-4/+3
| | | | | | | | | | | | | | | | the night realising that it was wrong :) I think the reason the same type was being used for the shufflevec of indices as for the actual indices is so that if one of them needs splitting then so does the other. After my patch it might be that the indices need splitting but not the rest, yet there is no good way of handling that. I think the right solution is to not have the shufflevec be an operand at all: just have it be the list of numbers it actually is, stored as extra info in the node. llvm-svn: 53768
* Use a legal type for elements of the vector_shuffleDuncan Sands2008-07-171-3/+4
| | | | | | | | | | | | | | | | | | mask. These are just indices into the shuffled vector so their type is unrelated to the type of the shuffled elements (which is what was being used before). This fixes vec_shuffle-11.ll when using LegalizeTypes. What seems to have happened is that Dan's recent change r53687, which corrected the result type of the shuffle, somehow caused LegalizeTypes to notice that the mask operand was a BUILD_VECTOR with a legal type but elements of an illegal type (i64). LegalizeTypes legalized this by introducing a new BUILD_VECTOR of i32 and bitcasting it to the old type. But the mask operand is not supposed to be a bitcast but a straight BUILD_VECTOR of constants, causing a crash. llvm-svn: 53729
* Fix the result type of a VECTOR_SHUFFLE+BIT_CONVERT dagcombine. ThisDan Gohman2008-07-161-3/+2
| | | | | | | was turned up by some new SelectionDAG assertion checks that I'm working on. llvm-svn: 53687
* Use reserve.Dan Gohman2008-06-301-0/+1
| | | | | | | | | | SelectionDAG::allnodes_size is linear, but that doesn't appear to outweigh the benefit of reducing heap traffic. If it does become a problem, we should teach SelectionDAG to keep a count of how many nodes are live, because there are several other places where that information would be useful as well. llvm-svn: 52926
* 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
* duncan points out that isOperationLegal includes a check forChris Lattner2008-06-261-2/+2
| | | | | | type legality. Thanks Duncan! llvm-svn: 52786
* 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
* Duncan pointed out this code could be tidied.Dan Gohman2008-06-231-6/+3
| | | | llvm-svn: 52624
* Simplify some getNode calls.Dan Gohman2008-06-211-6/+3
| | | | llvm-svn: 52604
* 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
* 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
* Disable some DAG combiner optimizations that may beDuncan Sands2008-06-131-58/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud