On Aug 14, 2007, at 9:22 AM, Chris Lattner wrote:
>
> On Aug 14, 2007, at 2:16 AM, Evan Cheng wrote:
>
>> Author: evancheng
>> Date: Tue Aug 14 04:16:00 2007
>> New Revision: 41070
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=41070&view=rev
>> Log:
>> Update test case. A spill should now be deleted.
>>
>> Modified:
>> llvm/trunk/test/CodeGen/X86/constant-pool-remat-0.ll
>
> Nice. I tweaked it to avoid the fpstack stuff on x86-32. I'm now
> getting:
More food for thought :). I tried this out on PPC and got the
following code:
_array:
mflr r0
stw r0, 8(r1)
stwu r1, -64(r1)
AAA stfd f14, 56(r1)
lis r2, ha16(LCPI1_0)
BBB lfs f14, lo16(LCPI1_0)(r2)
fmuls f1, f1, f14
bl L_qux$stub
fmuls f1, f1, f14
AAA lfd f14, 56(r1)
addi r1, r1, 64
lwz r0, 8(r1)
mtlr r0
blr
On PPC, this isn't a simple remat case, because the lfs instruction
uses r2 (BBB) (the same occurs on ARM, and it is a simple remat case
there). However, the thing I find interesting about this is that
remat'ing the load from the constant pool would avoid having to save/
restore the callee save register f14 (BBB). I don't know how common
this is, but I expect the same could happen on x86 with callee-save
GPRs as well. It seems tricky to handle well though.
-Chris
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
