Yes, I'll look into that.
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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
