[llvm-commits] [llvm] r41070 - /llvm/trunk/test/CodeGen/X86/constant-pool-remat-0.ll

[Chris Lattner]

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