[llvm-commits] [llvm] r40736 - in /llvm/trunk: lib/Target/X86/X86InstrMMX.td lib/Target/X86/X86InstrSSE.td test/CodeGen/X86/constant-pool-remat-0.ll

[Evan Cheng]

This is done. Now we emit this:

_array:
         subq    $8, %rsp
         mulss   LCPI1_0(%rip), %xmm0
         call    _qux
         mulss   LCPI1_0(%rip), %xmm0
         addq    $8, %rsp
         ret

Evan

On Aug 2, 2007, at 8:50 AM, Chris Lattner wrote:

>> Mark the SSE and MMX load instructions that
>> X86InstrInfo::isReallyTriviallyReMaterializable knows how to handle
>> with the isReMaterializable flag so that it is given a chance to
>> handle
>> them. Without hoisting constant-pool loads from loops this isn't very
>> visible, though it does keep CodeGen/X86/constant-pool-remat-0.ll  
>> from
>> making a copy of the constant pool on the stack.
>>
>> @@ -0,0 +1,10 @@
>> +; RUN: llvm-as < %s | llc -march=x86-64 | grep LCPI | wc -l | grep 3
>> +
>> +declare float @qux(float %y)
>> +
>> +define float @array(float %a) {
>> +  %n = mul float %a, 9.0
>> +  %m = call float @qux(float %n)
>> +  %o = mul float %m, 9.0
>> +  ret float %o
>> +}
>
> Interesting testcase.  I'm now getting:
>
> _array:
>          subq    $8, %rsp
>          movss   LCPI1_0(%rip), %xmm1
>          mulss   %xmm1, %xmm0
>          call    _qux
>          movss   LCPI1_0(%rip), %xmm1
>          mulss   %xmm1, %xmm0
>          addq    $8, %rsp
>          ret
>
> for this.  Both loads should be folded into the mulss's.  Because the
> load is shared at isel time, this can't be done there, but it can be
> done after the remat.  Maybe the register allocator needs to call
> MRegisterInfo::foldMemoryOperand if the remat is a load that has a
> single use?
>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits