summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add contexts to some of the MVT APIs. No functionality change yet, just the ↵Owen Anderson2009-08-121-16/+17
| | | | | | infrastructure work needed to get the contexts to where they need to be first. llvm-svn: 78759
* Split EVT into MVT and EVT, the former representing _just_ a primitive type, ↵Owen Anderson2009-08-111-62/+62
| | | | | | | | while the latter is capable of representing either a primitive or an extended type. llvm-svn: 78713
* Fix a bug in the DAGCombiner's handling of multiple linkedDan Gohman2009-08-101-3/+8
| | | | | | | | | | | MERGE_VALUES nodes. Replacing the result values with the operands in one MERGE_VALUES node may cause another MERGE_VALUES node be CSE'd with the first one, and bring its uses along, so that the first one isn't dead, as this code expects. Fix this by iterating until the node is really dead. This fixes PR4699. llvm-svn: 78619
* Fix a bug where DAGCombine was producing an illegal ConstantFPDan Gohman2009-08-101-1/+12
| | | | | | | node after legalize, and remove the workaround code from the ARM backend. llvm-svn: 78615
* Rename MVT to EVT, in preparation for splitting SimpleValueType out into its ↵Owen Anderson2009-08-101-195/+195
| | | | | | own struct type. llvm-svn: 78610
* Make this comment more closely reflect the code.Dan Gohman2009-08-101-1/+1
| | | | llvm-svn: 78569
* Don't build illegal ops in DAGCombiner::SimplifyBinOpWithSameOpcodeHands().Jakob Stoklund Olesen2009-08-081-1/+3
| | | | | | | | Blackfin supports and/or/xor on i32 but not on i16. Teach DAGCombiner::SimplifyBinOpWithSameOpcodeHands to not produce illegal nodes after legalize ops. llvm-svn: 78497
* Fix a few places in DAGCombiner that were creating all-ones-bitsDan Gohman2009-08-061-5/+17
| | | | | | | | and high-bits values in ways that weren't correct for integer types wider than 64 bits. This fixes a miscompile in PPMacroExpansion.cpp in clang on x86-64. llvm-svn: 78295
* Avoid forming a SELECT_CC in a type that the target doesn'tDan Gohman2009-08-021-1/+2
| | | | | | | | | | | | | | | | | | | support. This isn't immediately interesting, because Legalize ends up lowering SELECT_CC if the target doesn't support it, but this simplifies the process. Also, if the SELECT_CC would be expanded in Legalize, it can potentially end up with two copies of the condition expression. By leaving it as SELECT+SETCC, the SELECT can be expanded into two SELECTs that use a single SETCC. The two comparisons are usually CSE'd, but depending on when various expressions get legalized, the comparison expression could involve calls to library functions, such that the comparison expression may not be able to be CSE'd. This will be needed by a future patch. llvm-svn: 77896
* Move types back to the 2.5 API.Owen Anderson2009-07-291-9/+6
| | | | llvm-svn: 77516
* Change ConstantArray to 2.5 API.Owen Anderson2009-07-281-1/+1
| | | | llvm-svn: 77347
* Add support for promoting SETCC operations.Jakob Stoklund Olesen2009-07-241-2/+2
| | | | llvm-svn: 76987
* Fix a dagga combiner bug: avoid creating illegal constant.Evan Cheng2009-07-211-9/+12
| | | | | | | | Is this really a winning transformation? fold (shl (srl x, c1), c2) -> (shl (and x, (shl -1, c1)), (sub c2, c1)) or (srl (and x, (shl -1, c1)), (sub c1, c2)) llvm-svn: 76535
* Move a few more convenience factory functions from Constant to LLVMContext.Owen Anderson2009-07-151-1/+3
| | | | llvm-svn: 75840
* llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable.Torok Edwin2009-07-141-4/+4
| | | | | | | | | This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
* assert(0) -> LLVM_UNREACHABLE.Torok Edwin2009-07-111-3/+3
| | | | | | | | | Make llvm_unreachable take an optional string, thus moving the cerr<< out of line. LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for NDEBUG builds. llvm-svn: 75379
* Convert more assert(0)+abort() -> LLVM_UNREACHABLE,Torok Edwin2009-07-111-2/+2
| | | | | | and abort()/exit() -> llvm_report_error(). llvm-svn: 75363
* Thread LLVMContext through MVT and related parts of SDISel.Owen Anderson2009-07-091-5/+7
| | | | llvm-svn: 75153
* dag combine sext(setcc) -> vsetcc before legalize. To make this safe,Chris Lattner2009-07-081-1/+19
| | | | | | | | | VSETCC must define all bits, which is different than it was documented to before. Since all targets that implement VSETCC already have this behavior, and we don't optimize based on this, just change the documentation. We now get nice code for vec_compare.ll llvm-svn: 74978
* Adapt the x86 build_vector dagcombine to the current state of the legalizer.Nate Begeman2009-06-051-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | build vectors with i64 elements will only appear on 32b x86 before legalize. Since vector widening occurs during legalize, and produces i64 build_vector elements, the dag combiner is never run on these before legalize splits them into 32b elements. Teach the build_vector dag combine in x86 back end to recognize consecutive loads producing the low part of the vector. Convert the two uses of TLI's consecutive load recognizer to pass LoadSDNodes since that was required implicitly. Add a testcase for the transform. Old: subl $28, %esp movl 32(%esp), %eax movl 4(%eax), %ecx movl %ecx, 4(%esp) movl (%eax), %eax movl %eax, (%esp) movaps (%esp), %xmm0 pmovzxwd %xmm0, %xmm0 movl 36(%esp), %eax movaps %xmm0, (%eax) addl $28, %esp ret New: movl 4(%esp), %eax pmovzxwd (%eax), %xmm0 movl 8(%esp), %eax movaps %xmm0, (%eax) ret llvm-svn: 72957
* Don't do the X * 0.0 -> 0.0 transformation in instcombine, becauseDan Gohman2009-06-041-0/+3
| | | | | | | | instcombine doesn't know when it's safe. To partially compensate for this, introduce new code to do this transformation in dagcombine, which can use UnsafeFPMath. llvm-svn: 72872
* Revert 72707 and 72709, for the moment.Dale Johannesen2009-06-021-7/+9
| | | | llvm-svn: 72712
* Make the implicit inputs and outputs of target-independentDale Johannesen2009-06-011-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | ADDC/ADDE use MVT::i1 (later, whatever it gets legalized to) instead of MVT::Flag. Remove CARRY_FALSE in favor of 0; adjust all target-independent code to use this format. Most targets will still produce a Flag-setting target-dependent version when selection is done. X86 is converted to use i32 instead, which means TableGen needs to produce different code in xxxGenDAGISel.inc. This keys off the new supportsHasI1 bit in xxxInstrInfo, currently set only for X86; in principle this is temporary and should go away when all other targets have been converted. All relevant X86 instruction patterns are modified to represent setting and using EFLAGS explicitly. The same can be done on other targets. The immediate behavior change is that an ADC/ADD pair are no longer tightly coupled in the X86 scheduler; they can be separated by instructions that don't clobber the flags (MOV). I will soon add some peephole optimizations based on using other instructions that set the flags to feed into ADC. llvm-svn: 72707
* Do not try to create a MVT type of width 0.Evan Cheng2009-05-281-0/+2
| | | | llvm-svn: 72557
* Incorporate patch feedbacks.Evan Cheng2009-05-281-11/+17
| | | | llvm-svn: 72533
* Added optimization that narrow load / op / store and the 'op' is a bit ↵Evan Cheng2009-05-281-1/+93
| | | | | | | | | | | | | twiddling instruction and its second operand is an immediate. If bits that are touched by 'op' can be done with a narrower instruction, reduce the width of the load and store as well. This happens a lot with bitfield manipulation code. e.g. orl $65536, 8(%rax) => orb $1, 10(%rax) Since narrowing is not always a win, e.g. i32 -> i16 is a loss on x86, dag combiner consults with the target before performing the optimization. llvm-svn: 72507
* Fix PR4254.Torok Edwin2009-05-231-2/+2
| | | | | | | | | | | The DAGCombiner created a negative shiftamount, stored in an unsigned variable. Later the optimizer eliminated the shift entirely as being undefined. Example: (srl (shl X, 56) 48). ShiftAmt is 4294967288. Fix it by checking that the shiftamount is positive, and storing in a signed variable. llvm-svn: 72331
* Silence Release-Asserts warnings.Daniel Dunbar2009-05-181-6/+6
| | | | llvm-svn: 72011
* Rename PaddedSize to AllocSize, in the hope that thisDuncan Sands2009-05-091-1/+1
| | | | | | | will make it more obvious what it represents, and stop it being confused with the StoreSize. llvm-svn: 71349
* Do not use register as base ptr of pre- and post- inc/dec load / store nodes.Evan Cheng2009-05-061-1/+4
| | | | llvm-svn: 71098
* Instead of passing in an unsigned value for the optimization level, use an enum,Bill Wendling2009-04-291-5/+5
| | | | | | | which better identifies what the optimization is doing. And is more flexible for future uses. llvm-svn: 70440
* Implement review feedback for vector shuffle work.Nate Begeman2009-04-291-6/+14
| | | | llvm-svn: 70372
* Second attempt:Bill Wendling2009-04-291-7/+8
| | | | | | | | | | | | Massive check in. This changes the "-fast" flag to "-O#" in llc. If you want to use the old behavior, the flag is -O0. This change allows for finer-grained control over which optimizations are run at different -O levels. Most of this work was pretty mechanical. The majority of the fixes came from verifying that a "fast" variable wasn't used anymore. The JIT still uses a "Fast" flag. I'll change the JIT with a follow-up patch. llvm-svn: 70343
* r70270 isn't ready yet. Back this out. Sorry for the noise.Bill Wendling2009-04-281-8/+7
| | | | llvm-svn: 70275
* Massive check in. This changes the "-fast" flag to "-O#" in llc. If you want toBill Wendling2009-04-281-7/+8
| | | | | | | | | | | use the old behavior, the flag is -O0. This change allows for finer-grained control over which optimizations are run at different -O levels. Most of this work was pretty mechanical. The majority of the fixes came from verifying that a "fast" variable wasn't used anymore. The JIT still uses a "Fast" flag. I'm not 100% sure if it's necessary to change it there... llvm-svn: 70270
* 2nd attempt, fixing SSE4.1 issues and implementing feedback from duncan.Nate Begeman2009-04-271-143/+49
| | | | | | | | | | | | | | PR2957 ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes as the shuffle mask. A value of -1 represents UNDEF. In addition to eliminating the creation of illegal BUILD_VECTORS just to represent shuffle masks, we are better about canonicalizing the shuffle mask, resulting in substantially better code for some classes of shuffles. llvm-svn: 70225
* When transforming sext(trunc(load(x))) into sext(smaller load(x)),Dan Gohman2009-04-271-1/+1
| | | | | | | the trunc is directly replaced with the smaller load, so don't try to create a new sext node. This fixes PR4050. llvm-svn: 70179
* Add a top-level comment about DAGCombiner's role in the compiler.Dan Gohman2009-04-251-0/+4
| | | | llvm-svn: 70052
* Revert 69952. Causes testsuite failures on linux x86-64.Rafael Espindola2009-04-241-49/+143
| | | | llvm-svn: 69967
* PR2957Nate Begeman2009-04-241-143/+49
| | | | | | | | | | | | | | ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes as the shuffle mask. A value of -1 represents UNDEF. In addition to eliminating the creation of illegal BUILD_VECTORS just to represent shuffle masks, we are better about canonicalizing the shuffle mask, resulting in substantially better code for some classes of shuffles. A clean up of x86 shuffle code, and some canonicalizing in DAGCombiner is next. llvm-svn: 69952
* Revise my previous change 68996 as suggested by Duncan.Bob Wilson2009-04-201-6/+2
| | | | llvm-svn: 69607
* Don't try to make BUILD_VECTOR operands have the sameDuncan Sands2009-04-181-2/+9
| | | | | | | | | | | | | | | | | type as the vector element type: allow them to be of a wider integer type than the element type all the way through the system, and not just as far as LegalizeDAG. This should be safe because it used to be this way (the old type legalizer would produce such nodes), so backends should be able to handle it. In fact only targets which have legal vector types with an illegal promoted element type will ever see this (eg: <4 x i16> on ppc). This fixes a regression with the new type legalizer (vec_splat.ll). Also, treat SCALAR_TO_VECTOR the same as BUILD_VECTOR. After all, it is just a special case of BUILD_VECTOR. llvm-svn: 69467
* Change SelectionDAG type legalization to allow BUILD_VECTOR operands to beBob Wilson2009-04-131-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | promoted to legal types without changing the type of the vector. This is following a suggestion from Duncan (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/019923.html). The transformation that used to be done during type legalization is now postponed to DAG legalization. This allows the BUILD_VECTORs to be optimized and potentially handled specially by target-specific code. It turns out that this is also consistent with an optimization done by the DAG combiner: a BUILD_VECTOR and INSERT_VECTOR_ELT may be combined by replacing one of the BUILD_VECTOR operands with the newly inserted element; but INSERT_VECTOR_ELT allows its scalar operand to be larger than the element type, with any extra high bits being implicitly truncated. The result is a BUILD_VECTOR where one of the operands has a type larger the the vector element type. Any code that operates on BUILD_VECTORs may now need to be aware of the potential type discrepancy between the vector element type and the BUILD_VECTOR operands. This patch updates all of the places that I could find to handle that case. llvm-svn: 68996
* Generalize ExtendUsesToFormExtLoad to be usable for ANY_EXTEND,Dan Gohman2009-04-091-43/+60
| | | | | | | | | | | | | | | in addition to ZERO_EXTEND and SIGN_EXTEND. Fix a bug in the way it checked for live-out values, and simplify the way it find users by using SDNode::use_iterator's (relatively) new features. Also, make it slightly more permissive on targets with free truncates. In SelectionDAGBuild, avoid creating ANY_EXTEND nodes that are larger than necessary. If the target's SwitchAmountTy has enough bits, use it. This exposes the truncate to optimization early, enabling more optimizations. llvm-svn: 68670
* Implement support for using modeling implicit-zero-extension on x86-64Dan Gohman2009-04-081-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with SUBREG_TO_REG, teach SimpleRegisterCoalescing to coalesce SUBREG_TO_REG instructions (which are similar to INSERT_SUBREG instructions), and teach the DAGCombiner to take advantage of this on targets which support it. This eliminates many redundant zero-extension operations on x86-64. This adds a new TargetLowering hook, isZExtFree. It's similar to isTruncateFree, except it only applies to actual definitions, and not no-op truncates which may not zero the high bits. Also, this adds a new optimization to SimplifyDemandedBits: transform operations like x+y into (zext (add (trunc x), (trunc y))) on targets where all the casts are no-ops. In contexts where the high part of the add is explicitly masked off, this allows the mask operation to be eliminated. Fix the DAGCombiner to avoid undoing these transformations to eliminate casts on targets where the casts are no-ops. Also, this adds a new two-address lowering heuristic. Since two-address lowering runs before coalescing, it helps to be able to look through copies when deciding whether commuting and/or three-address conversion are profitable. Also, fix a bug in LiveInterval::MergeInClobberRanges. It didn't handle the case that a clobber range extended both before and beyond an existing live range. In that case, multiple live ranges need to be added. This was exposed by the new subreg coalescing code. Remove 2008-05-06-SpillerBug.ll. It was bugpoint-reduced, and the spiller behavior it was looking for no longer occurrs with the new instruction selection. llvm-svn: 68576
* Optimize some 64-bit multiplication by constants into two lea's or one lea + ↵Evan Cheng2009-03-281-8/+8
| | | | | | | | | | | | | | | | | shl since imulq is slow (latency 5). e.g. x * 40 => shlq $3, %rdi leaq (%rdi,%rdi,4), %rax This has the added benefit of allowing more multiply to be folded into addressing mode. e.g. a * 24 + b => leaq (%rdi,%rdi,2), %rax leaq (%rsi,%rax,8), %rax llvm-svn: 67917
* Pull transform from target-dependent code into target-independent code.Bill Wendling2009-03-261-0/+49
| | | | llvm-svn: 67742
* Fix a problem with DAGCombine where we were building an illegal buildMon P Wang2009-03-171-6/+11
| | | | | | | | vector shuffle mask. Forced the mask to be built using i32. Note: this will be irrelevant once vector_shuffle no longer takes a build vector for the shuffle mask. llvm-svn: 67076
* Avoid doing the transformation c ? 1.0 : 2.0 as load { 2.0, 1.0 } + c*4Mon P Wang2009-03-141-1/+4
| | | | | | | if FPConstant is legal because if the FPConstant doesn't need to be stored in a constant pool, the transformation is unlikely to be profitable. llvm-svn: 66994
* Fix some significant problems with constant pools that resulted in ↵Evan Cheng2009-03-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | unnecessary paddings between constant pool entries, larger than necessary alignments (e.g. 8 byte alignment for .literal4 sections), and potentially other issues. 1. ConstantPoolSDNode alignment field is log2 value of the alignment requirement. This is not consistent with other SDNode variants. 2. MachineConstantPool alignment field is also a log2 value. 3. However, some places are creating ConstantPoolSDNode with alignment value rather than log2 values. This creates entries with artificially large alignments, e.g. 256 for SSE vector values. 4. Constant pool entry offsets are computed when they are created. However, asm printer group them by sections. That means the offsets are no longer valid. However, asm printer uses them to determine size of padding between entries. 5. Asm printer uses expensive data structure multimap to track constant pool entries by sections. 6. Asm printer iterate over SmallPtrSet when it's emitting constant pool entries. This is non-deterministic. Solutions: 1. ConstantPoolSDNode alignment field is changed to keep non-log2 value. 2. MachineConstantPool alignment field is also changed to keep non-log2 value. 3. Functions that create ConstantPool nodes are passing in non-log2 alignments. 4. MachineConstantPoolEntry no longer keeps an offset field. It's replaced with an alignment field. Offsets are not computed when constant pool entries are created. They are computed on the fly in asm printer and JIT. 5. Asm printer uses cheaper data structure to group constant pool entries. 6. Asm printer compute entry offsets after grouping is done. 7. Change JIT code to compute entry offsets on the fly. llvm-svn: 66875
OpenPOWER on IntegriCloud