summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Various tweaks related to apint codegen. No functionalityDuncan Sands2008-06-093-4/+4
| | | | | | change for non-funky-sized integers. llvm-svn: 52151
* Handle empty aggregate values.Dan Gohman2008-06-091-21/+22
| | | | llvm-svn: 52150
* 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-089-89/+75
| | | | | | | | | | | 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
* CodeGen support for insertvalue and extractvalue, and for loads andDan Gohman2008-06-071-26/+233
| | | | | | stores of aggregate values. llvm-svn: 52069
* Connect successors before creating the DAG node for the branch. This hasOwen Anderson2008-06-071-22/+24
| | | | | | | no visible functionality change, but enables a future patch where node creation will update the CFG if it decides to create an unconditional rather than a conditional branch. llvm-svn: 52067
* Tighten up the abstraction slightly.Duncan Sands2008-06-061-10/+10
| | | | llvm-svn: 52045
* Wrap MVT::ValueType in a struct to get type safetyDuncan Sands2008-06-0616-1279/+1255
| | | | | | | | | | | | | | | | 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
* Fix a memcpy lowering bug. Even though the memcpy alignment is smaller than ↵Evan Cheng2008-06-041-2/+3
| | | | | | the desired alignment, the frame destination alignment may still be larger than the desired alignment. Don't change its alignment to something smaller. llvm-svn: 51970
* Fix spellnig errorScott Michel2008-06-031-6/+5
| | | | llvm-svn: 51917
* Fold adds and subtracts of zero immediately, instead of waitingDan Gohman2008-06-021-4/+4
| | | | | | for dagcombine to do this. llvm-svn: 51886
* Add necessary 64-bit support so that gcc frontend compiles (mostly). CurrentScott Michel2008-06-021-1/+10
| | | | | | | issue is operand promotion for setcc/select... but looks like the fundamental stuff is implemented for CellSPU. llvm-svn: 51884
* Remove an unused variable.Dan Gohman2008-05-311-1/+0
| | | | llvm-svn: 51807
* Remove an unused variable.Dan Gohman2008-05-301-1/+0
| | | | llvm-svn: 51721
* Expand small memmovs using inline code. Set the X86 threshold for expandingDan Gohman2008-05-291-5/+73
| | | | | | memmove to a more plausible value, now that it's actually being used. llvm-svn: 51696
* Implement vector shift up / down and insert zero with ps{rl}lq / ps{rl}ldq.Evan Cheng2008-05-291-3/+10
| | | | llvm-svn: 51667
* Fix some constructs that gcc-4.4 warns about.Duncan Sands2008-05-271-1/+1
| | | | llvm-svn: 51591
* Add #includes to make some dependencies explicit.Dan Gohman2008-05-231-0/+1
| | | | llvm-svn: 51496
* Generalize the new code in instcombine's ComputeNumSignBits for handlingDan Gohman2008-05-231-7/+13
| | | | | | | and/or to handle more cases (such as this add-sitofp.ll testcase), and port it to selectiondag's ComputeNumSignBits. llvm-svn: 51469
* Use isSingleValueType instead of isFirstClassType toDan Gohman2008-05-231-2/+2
| | | | | | exclude struct and array types. llvm-svn: 51460
* Port the fix for the select operator from instcombine'sDan Gohman2008-05-201-2/+2
| | | | | | ComputeNumSignBits to SelectionDAG's ComputeNumSignBits. llvm-svn: 51348
* Code simplification.Dan Gohman2008-05-201-6/+4
| | | | llvm-svn: 51345
* If the result of a BIT_CONVERT is a v1* vector, it doesn't mean its source ↵Evan Cheng2008-05-161-3/+6
| | | | | | is a v1* vector. llvm-svn: 51192
* Silence the compiler warning differently. TheDuncan Sands2008-05-161-1/+1
| | | | | | original method caused gcc-4.2 to complain. llvm-svn: 51186
* Actually scalarize the operand to BIT_CONVERT instead of asking someone to doNate Begeman2008-05-151-1/+2
| | | | | | something with a v1 type. llvm-svn: 51160
OpenPOWER on IntegriCloud