[PATCH] [AArch64] enable rematerialization of float 0 values
qcolombet at apple.com
Fri Mar 20 09:45:50 PDT 2015
> On Mar 19, 2015, at 5:30 PM, Matthias Braun <mbraun at apple.com> wrote:
> 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…
Yes, the assumption is that the flag is only set on reasonably cheap instructions. If rematerialization is more expensive than spillingthen there is no point in doing it :).
> - 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.
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits