summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Enable stack coloring by default.Evan Cheng2008-06-062-8/+11
| | | | llvm-svn: 52057
* 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
* Refine stack slot interval weight computation.Evan Cheng2008-06-062-23/+58
| | | | llvm-svn: 52040
* Remove debugging code.Owen Anderson2008-06-051-4/+0
| | | | llvm-svn: 52016
* Use the newly created helper on LiveIntervals.Owen Anderson2008-06-051-116/+21
| | | | llvm-svn: 52013
* Add a helper for constructing new live ranges that ended from an instruction ↵Owen Anderson2008-06-051-0/+15
| | | | | | to the end of its MBB. llvm-svn: 52012
* 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
* Oops. Should not be enabled by default.Evan Cheng2008-06-041-1/+1
| | | | llvm-svn: 51953
* Correctly construct live intervals for the copies we inserted into the ↵Owen Anderson2008-06-041-1/+38
| | | | | | predecessors of a block containing a PHI. llvm-svn: 51950
* Revert this.Evan Cheng2008-06-041-4/+0
| | | | llvm-svn: 51949
* Add a stack slot coloring pass. Not yet enabled.Evan Cheng2008-06-046-38/+412
| | | | llvm-svn: 51934
* LowerSubregs should not clobber any analysis.Evan Cheng2008-06-041-0/+4
| | | | llvm-svn: 51933
* Move #include to right place.Evan Cheng2008-06-042-1/+1
| | | | llvm-svn: 51932
* Register if-converter pass for -debug-pass.Evan Cheng2008-06-041-1/+4
| | | | llvm-svn: 51931
* Change packed struct layout so that field sizesDuncan Sands2008-06-041-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | are the same as in unpacked structs, only field positions differ. This only matters for structs containing x86 long double or an apint; it may cause backwards compatibility problems if someone has bitcode containing a packed struct with a field of one of those types. The issue is that only 10 bytes are needed to hold an x86 long double: the store size is 10 bytes, but the ABI size is 12 or 16 bytes (linux/ darwin) which comes from rounding the store size up by the alignment. Because it seemed silly not to pack an x86 long double into 10 bytes in a packed struct, this is what was done. I now think this was a mistake. Reserving the ABI size for an x86 long double field even in a packed struct makes things more uniform: the ABI size is now always used when reserving space for a type. This means that developers are less likely to make mistakes. It also makes life easier for the CBE which otherwise could not represent all LLVM packed structs (PR2402). Front-end people might need to adjust the way they create LLVM structs - see following change to llvm-gcc. llvm-svn: 51928
* We need to subtract one from this index because live ranges are open at the end.Owen Anderson2008-06-041-1/+1
| | | | llvm-svn: 51922
* Fix spellnig errorScott Michel2008-06-031-6/+5
| | | | llvm-svn: 51917
* Find a better place to output hex constants corresponding to integers.Scott Michel2008-06-031-0/+5
| | | | llvm-svn: 51904
* Fixed bug in bad behavior in calculateFrameObjectOffsets,Bruno Cardoso Lopes2008-06-031-1/+2
| | | | | | | the solution commited is different from the previous patch to avoid int and unsigned comparison llvm-svn: 51899
* Do not run loop-aligner at -fast (e.g. -O0).Evan Cheng2008-06-031-1/+1
| | | | llvm-svn: 51898
* Revert this patchScott Michel2008-06-031-3/+1
| | | | llvm-svn: 51897
* Fold adds and subtracts of zero immediately, instead of waitingDan Gohman2008-06-021-4/+4
| | | | | | for dagcombine to do this. llvm-svn: 51886
* Minor cosmetic patch so that the hex equivalent of a decimalScott Michel2008-06-021-1/+3
| | | | | | | constant shows up in the assembly language output. Helps with debugging without a HP calculator having to be handy. llvm-svn: 51885
* 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
* Correctly handle removed instructions at the beginning of MBBs when renumbering.Owen Anderson2008-06-021-12/+8
| | | | llvm-svn: 51876
* Remove an unused variable.Dan Gohman2008-05-311-1/+0
| | | | llvm-svn: 51807
* Fix indentation.Evan Cheng2008-05-301-1/+1
| | | | llvm-svn: 51793
* The coalescer doesn't need LiveVariables now that we have register use ↵Owen Anderson2008-05-302-15/+6
| | | | | | iterators. llvm-svn: 51790
* Preserve the register coallescer, and update live intervals more correctly ↵Owen Anderson2008-05-301-1/+4
| | | | | | by triggering a renumbering after phi elimination. llvm-svn: 51780
* Remove an unused variable.Dan Gohman2008-05-301-1/+0
| | | | llvm-svn: 51721
* Make the renumbering correct in the face of deleted instructions that have ↵Owen Anderson2008-05-291-7/+73
| | | | | | been removed from the LiveIntervals maps. llvm-svn: 51714
* Remove <iostream>.Bill Wendling2008-05-291-2/+0
| | | | llvm-svn: 51704
* 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
* Revert part of my last patch that I didn't intend to commit yet.Owen Anderson2008-05-291-0/+2
| | | | llvm-svn: 51694
* Renumbering needs to account for instruction slot offsets when performing ↵Owen Anderson2008-05-291-7/+20
| | | | | | lookups in the index maps. llvm-svn: 51691
* Implement vector shift up / down and insert zero with ps{rl}lq / ps{rl}ldq.Evan Cheng2008-05-291-3/+10
| | | | llvm-svn: 51667
* Implement "AsCheapAsAMove" for some obviously cheap instructions: xor and theBill Wendling2008-05-291-1/+4
| | | | | | like. llvm-svn: 51662
* Add a flag to indicate that an instruction is as cheap (or cheaper) than a moveBill Wendling2008-05-281-3/+3
| | | | | | | | | instruction to execute. This can be used for transformations (like two-address conversion) to remat an instruction instead of generating a "move" instruction. The idea is to decrease the live ranges and register pressure and all that jazz. llvm-svn: 51660
* Check the "isSafeToMove" predicate, which has a series of tests to make sureBill Wendling2008-05-281-1/+3
| | | | | | that it's safe to remat an instruction. llvm-svn: 51659
OpenPOWER on IntegriCloud