- Nov 02, 2006
-
-
Evan Cheng authored
llvm-svn: 31364
-
Evan Cheng authored
Two-address instructions no longer have to be A := A op C. Now any pair of dest / src operands can be tied together. llvm-svn: 31363
-
- Oct 12, 2006
-
-
Chris Lattner authored
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061009/038518.html llvm-svn: 30906
-
Evan Cheng authored
It's turning: movl -24(%ebp), %esp subl $16, %esp movl -24(%ebp), %ecx into movl -24(%ebp), %esp subl $16, %esp movl %esp, (%esp) llvm-svn: 30902
-
Chris Lattner authored
the stack slot. This fixes PR943. llvm-svn: 30898
-
- Sep 05, 2006
-
-
Chris Lattner authored
actually *removes* one of the operands, instead of just assigning both operands the same register. This make reasoning about instructions unnecessarily complex, because you need to know if you are before or after register allocation to match up operand #'s with the target description file. Changing this also gets rid of a bunch of hacky code in various places. This patch also includes changes to fold loads into cmp/test instructions in the X86 backend, along with a significant simplification to the X86 spill folding code. llvm-svn: 30108
-
- Aug 27, 2006
-
-
Chris Lattner authored
llvm-svn: 29911
-
- Aug 25, 2006
-
-
Chris Lattner authored
instructions which define each value#) to simplify and improve the coallescer. In particular, this patch: 1. Implements iterative coallescing. 2. Reverts an unsafe hack from handlePhysRegDef, superceeding it with a better solution. 3. Implements PR865, "coallescing" away the second copy in code like: A = B ... B = A This also includes changes to symbolically print registers in intervals when possible. llvm-svn: 29862
-
- Aug 21, 2006
-
-
Bill Wendling authored
MOV R0, R1 MOV R1, R0 the second machine instruction is removed. Added a regression test. llvm-svn: 29792
-
- Jul 21, 2006
-
-
Jim Laskey authored
llvm-svn: 29250
-
- Jul 20, 2006
-
-
Andrew Lenharth authored
llvm-svn: 29220
-
- Jun 29, 2006
-
-
Chris Lattner authored
llvm-svn: 28973
-
- May 04, 2006
-
-
Chris Lattner authored
llvm-svn: 28102
-
- May 02, 2006
-
-
Chris Lattner authored
instructions in the virtregfolded map that were deleted. Because they were deleted, newly allocated instructions could end up at the same address, magically finding themselves in the map. The solution is to remove entries from the map when we delete the instructions. llvm-svn: 28041
-
- May 01, 2006
-
-
Chris Lattner authored
instruction folded with spill code, make sure the remove the load from the virt reg folded map. llvm-svn: 28040
-
Chris Lattner authored
llvm-svn: 28039
-
Evan Cheng authored
Remove temp. option -spiller-check-liveout, it didn't cause any failure nor performance regressions. llvm-svn: 28029
-
- Apr 30, 2006
-
-
Evan Cheng authored
But this is incorrect if the spilled value live range extends beyond the current BB. It is currently controlled by a temporary option -spiller-check-liveout. llvm-svn: 28024
-
- Apr 28, 2006
-
-
Chris Lattner authored
the same. In this case, don't emit a noop copy. llvm-svn: 28008
-
Chris Lattner authored
and is already available, instead of falling back to emitting a load, fall back to emitting a reg-reg copy. This generates significantly better code for some SSE testcases, as SSE has lots of two-address instructions and none of them are read/modify/write. As one example, this change does: pshufd %XMM5, XMMWORD PTR [%ESP + 84], 255 xorps %XMM2, %XMM5 cmpltps %XMM1, %XMM0 - movaps XMMWORD PTR [%ESP + 52], %XMM0 - movapd %XMM6, XMMWORD PTR [%ESP + 52] + movaps %XMM6, %XMM0 cmpltps %XMM6, XMMWORD PTR [%ESP + 68] movapd XMMWORD PTR [%ESP + 52], %XMM6 movaps %XMM6, %XMM0 cmpltps %XMM6, XMMWORD PTR [%ESP + 36] cmpltps %XMM3, %XMM0 - movaps XMMWORD PTR [%ESP + 20], %XMM0 - movapd %XMM7, XMMWORD PTR [%ESP + 20] + movaps %XMM7, %XMM0 cmpltps %XMM7, XMMWORD PTR [%ESP + 4] movapd XMMWORD PTR [%ESP + 20], %XMM7 cmpltps %XMM4, %XMM0 ... which is far better than a store followed by a load! llvm-svn: 28001
-
- Feb 25, 2006
-
-
Chris Lattner authored
exposed with a fastcc problem (breaking pcompress2 on x86 with -enable-x86-fastcc). When reloading a reused reg, make sure to invalidate the reloaded reg, and check to see if there are any other pending uses of the same register. llvm-svn: 26369
-
Chris Lattner authored
Add a minor compile time win, no codegen change. llvm-svn: 26368
-
Chris Lattner authored
This gets rid of two gotos, which is always nice, and also adds some comments. No functionality change, this is just a refactor. llvm-svn: 26367
-
- Feb 04, 2006
-
-
Jeff Cohen authored
llvm-svn: 25957
-
Chris Lattner authored
llvm-svn: 25949
-
Chris Lattner authored
store EAX -> [ss#0] [ss#0] += 1 ... use(EAX) In this case, it is not valid to rewrite this as: store EAX -> [ss#0] EAX += 1 store EAX -> [ss#0] ;;; this would also delete the store above ... use(EAX) ... because EAX is not a dead at that point. Keep track of which registers we are allowed to clobber, and which ones we aren't, and don't clobber the ones we're not supposed to. :) This should resolve the issues on X86 last night. llvm-svn: 25948
-
Chris Lattner authored
and PhysRegsAvailable maps out into a new AvailableSpills struct. No functionality change. This paves the way for a bugfix, coming up next. llvm-svn: 25947
-
- Feb 03, 2006
-
-
Jeff Cohen authored
a std::multimap iterator value. For some reason, GCC doesn't have a problem with this. llvm-svn: 25927
-
Chris Lattner authored
llvm-svn: 25926
-
Chris Lattner authored
llvm-svn: 25924
-
Chris Lattner authored
1. a target doesn't know how to fold load/stores into copies, or 2. the spiller rewrites the input to a copy to the same register as the dest instead of to the reloaded reg. This will be moved/improved in the near future, but allows elimination of some ancient x86 hacks. This eliminates 92 copies from SMG2000 on X86 and 163 copies from 252.eon. llvm-svn: 25922
-
Chris Lattner authored
of this, and use it to our advantage (bwahahah). This allows us to eliminate another 60 instructions from smg2000 on PPC (probably significantly more on X86). A common old-new diff looks like this: stw r2, 3304(r1) - lwz r2, 3192(r1) stw r2, 3300(r1) - lwz r2, 3192(r1) stw r2, 3296(r1) - lwz r2, 3192(r1) stw r2, 3200(r1) - lwz r2, 3192(r1) stw r2, 3196(r1) - lwz r2, 3192(r1) + or r2, r2, r2 stw r2, 3188(r1) and - lwz r31, 604(r1) - lwz r13, 604(r1) - lwz r14, 604(r1) - lwz r15, 604(r1) - lwz r16, 604(r1) - lwz r30, 604(r1) + or r31, r30, r30 + or r13, r30, r30 + or r14, r30, r30 + or r15, r30, r30 + or r16, r30, r30 + or r30, r30, r30 Removal of the R = R copies is coming next... llvm-svn: 25919
-
Chris Lattner authored
this code: store [stack slot #0], R10 = add R14, [stack slot #0] The spiller didn't know that the store made the value of [stackslot#0] available in R10 *IF* the store came from a copy instruction with the store folded into it. This patch teaches VirtRegMap to look at these stores and recognize the values they make available. In one case Evan provided, this code: divsd %XMM0, %XMM1 movsd %XMM1, QWORD PTR [%ESP + 40] 1) movsd QWORD PTR [%ESP + 48], %XMM1 2) movsd %XMM1, QWORD PTR [%ESP + 48] addsd %XMM1, %XMM0 3) movsd QWORD PTR [%ESP + 48], %XMM1 movsd QWORD PTR [%ESP + 4], %XMM0 turns into: divsd %XMM0, %XMM1 movsd %XMM1, QWORD PTR [%ESP + 40] addsd %XMM1, %XMM0 3) movsd QWORD PTR [%ESP + 48], %XMM1 movsd QWORD PTR [%ESP + 4], %XMM0 In this case, instruction #2 was removed because of the value made available by #1, and inst #1 was later deleted because it is now never used before the stack slot is redefined by #3. This occurs here and there in a lot of code with high spilling, on PPC most of the removed loads/stores are LSU-reject-causing loads, which is nice. On X86, things are much better (because it spills more), where we nuke about 1% of the instructions from SMG2000 and several hundred from eon. More improvements to come... llvm-svn: 25917
-
- Feb 02, 2006
-
-
Chris Lattner authored
Move isLoadFrom/StoreToStackSlot from MRegisterInfo to TargetInstrInfo,a far more logical place. Other methods should also be moved if anyoneis interested. :) llvm-svn: 25913
-
- Jan 23, 2006
-
-
Chris Lattner authored
llvm-svn: 25515
-
- Jan 04, 2006
-
-
Chris Lattner authored
don't help anyone) llvm-svn: 25081
-
- Oct 06, 2005
-
-
Chris Lattner authored
previous copy elisions and we discover we need to reload a register, make sure to use the regclass of the original register for the reload, not the class of the current register. This avoid using 16-bit loads to reload 32-bit values. llvm-svn: 23645
-
- Oct 05, 2005
-
-
Chris Lattner authored
store r12 -> [ss#2] R3 = load [ss#1] use R3 R3 = load [ss#2] R4 = load [ss#1] and turn it into this code: store R12 -> [ss#2] R3 = load [ss#1] use R3 R3 = R12 R4 = R3 <- oops! The problem was that promoting R3 = load[ss#2] to a copy missed the fact that the instruction invalidated R3 at that point. llvm-svn: 23638
-
- Sep 30, 2005
-
-
Chris Lattner authored
code. PrologEpilogInserter hasn't been updated yet though, so targets cannot use this info. llvm-svn: 23536
-
- Sep 19, 2005
-
-
Chris Lattner authored
when possible, avoiding the load (and avoiding the copy if the value is already in the right register). This patch came about when I noticed code like the following being generated: store R17 -> [SS1] ...blah... R4 = load [SS1] This was causing an LSU reject on the G5. This problem was due to the register allocator folding spill code into a reg-reg copy (producing the load), which prevented the spiller from being able to rewrite the load into a copy, despite the fact that the value was already available in a register. In the case above, we now rip out the R4 load and replace it with a R4 = R17 copy. This speeds up several programs on X86 (which spills a lot :) ), e.g. smg2k from 22.39->20.60s, povray from 12.93->12.66s, 168.wupwise from 68.54->53.83s (!), 197.parser from 7.33->6.62s (!), etc. This may have a larger impact in some cases on the G5 (by avoiding LSU rejects), though it probably won't trigger as often (less spilling in general). Targets that implement folding of loads/stores into copies should implement the isLoadFromStackSlot hook to get this. llvm-svn: 23388
-