[PATCH] [AArch64] enable rematerialization of float 0 values

Matthias Braun mbraun at apple.com
Thu Mar 19 17:30:42 PDT 2015


Out of interest I read the code related to the remat decisions. The final decision whether something is rematerializable happens in the isReallyTriviallyReMaterializable() TargetInstrInfo hook or in isReallyTriviallyRematerializableGeneric() which does not allow arbitrary register reads. There is an exception for constant physical registers (MRI.isConstantPhysReg()) however which should cover wzr/xzr. So in this case all should be fine.

I am indeed wondering if the flag is that usefull, the default logic appears to be reasonable safe to me. Except for the case of an instruction that takes unreasonably long to compute, I don't see why you would not set it on any instruction. Maybe I'll do some experiments of what happens when you switch the default for that flag to true...

- Matthias

> On Mar 19, 2015, at 5:08 PM, Tim Northover <t.p.northover at gmail.com> wrote:
> 
> Hi Geoff,
> 
>> On AArch64, float 0 values are currently being spilled/filled by the
>> register allocator instead of being more cheaply rematerialized.
> 
> This looks dodgy to me. It's marking every single UnscaledConversion
> as rematerializable (e.g. "fmov WS0, W0"), but it's only actually OK
> if the source register is wzr or xzr.
> 
> If that's safe (i.e. the rest of the pipeline can infer safety
> anyway), it would seem there's no need for the flag at all. So I think
> we need at least more justification of why it is OK.
> 
> Also, there are no tests here.
> 
> Cheers.
> 
> Tim.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits





More information about the llvm-commits mailing list