summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Sometimes (rarely) nodes held in LegalizeTypesDuncan Sands2008-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Various tweaks related to apint codegen. No functionalityDuncan Sands2008-06-091-2/+2
| | | | | | change for non-funky-sized integers. llvm-svn: 52151
* Remove some DAG combiner assumptions about sizesDuncan Sands2008-06-091-28/+21
| | | | | | | | | | | of integer types. Fix the isMask APInt method to actually work (hopefully) rather than crashing because it adds apints of different bitwidths. It looks like isShiftedMask is also broken, but I'm leaving that one to the APInt people (it is not used anywhere). llvm-svn: 52142
* Remove comparison methods for MVT. The main causeDuncan Sands2008-06-081-23/+21
| | | | | | | | | | | of apint codegen failure is the DAG combiner doing the wrong thing because it was comparing MVT's using < rather than comparing the number of bits. Removing the < method makes this mistake impossible to commit. Instead, add helper methods for comparing bits and use them. llvm-svn: 52098
* Wrap MVT::ValueType in a struct to get type safetyDuncan Sands2008-06-061-232/+232
| | | | | | | | | | | | | | | | and better control the abstraction. Rename the type to MVT. To update out-of-tree patches, the main thing to do is to rename MVT::ValueType to MVT, and rewrite expressions like MVT::getSizeInBits(VT) in the form VT.getSizeInBits(). Use VT.getSimpleVT() to extract a MVT::SimpleValueType for use in switch statements (you will get an assert failure if VT is an extended value type - these shouldn't exist after type legalization). This results in a small speedup of codegen and no new testsuite failures (x86-64 linux). llvm-svn: 52044
* Add #includes to make some dependencies explicit.Dan Gohman2008-05-231-0/+1
| | | | llvm-svn: 51496
* Code simplification.Dan Gohman2008-05-201-6/+4
| | | | llvm-svn: 51345
* Instead of a vector load, shuffle and then extract an element. Load the ↵Evan Cheng2008-05-131-33/+66
| | | | | | | | | | | element from address with an offset. pshufd $1, (%rdi), %xmm0 movd %xmm0, %eax => movl 4(%rdi), %eax llvm-svn: 51026
* Xform bitconvert(build_pair(load a, load b)) to a single load if the load ↵Evan Cheng2008-05-121-0/+49
| | | | | | locations are at the right offset from each other. llvm-svn: 51008
* Evan pointed out that folding sext to zext may not be correctDan Gohman2008-04-281-1/+2
| | | | | | if the zext is not legal. llvm-svn: 50368
* Teach DAGCombine to convert (sext x) to (zext x) when theDan Gohman2008-04-281-0/+4
| | | | | | sign-bit of x is known to be zero. llvm-svn: 50357
* Ongoing work on improving the instruction selection infrastructure:Roman Levenstein2008-04-161-1/+2
| | | | | | | | | | Rename SDOperandImpl back to SDOperand. Introduce the SDUse class that represents a use of the SDNode referred by an SDOperand. Now it is more similar to Use/Value classes. Patch is approved by Dan Gohman. llvm-svn: 49795
OpenPOWER on IntegriCloud