PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Qing Zhao QING.ZHAO@ORACLE.COM
Mon Sep 21 20:58:25 GMT 2020



> On Sep 21, 2020, at 3:34 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> 
> On Mon, Sep 21, 2020 at 09:13:58AM -0500, Qing Zhao wrote:
>>> On Sep 18, 2020, at 5:51 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>>>> B.  Will provide a default definition in middle end to generate the zeroing insn for selected registers. Then need to add a new target hook “ZERO_CALL_USED_REGNO_P(REGNO, GPR_ONLY)”, same as A, X86 implementation will be provided in my patch. 
>>> 
>>> Is this just to make the xor thing work?  i386 has a peephole to
>>> transform the mov to a xor for this (and the backend could just handle
>>> it in its mov<M> patterns, maybe a peephole was easier for i386, no
>>> idea).
>> 
>> You mean what’s the purpose of the new target hook “ZERO_CALL_USED_REGNO_P(REGNO, GPR_ONLY)?
>> 
>> The purpose of this new target hook is for the target to delete some of the call_used registers that should not be zeroed, for example, the stack registers in X86. (St0-st7). 
> 
> Oh, I didn't see the _P.  Maybe give it a better name?  Also, a better
> interface altogether, a call per hard register is a bit much (and easily
> avoidable).
> 
>> For other platforms, there might be other call_used registers that should not be zeroed. 
> 
> But you cannot *add* anything with this interface, and it cannot return
> different results depending on which return insn this is.  It is not a
> good abstraction IMO.

This hook will not depend on which return insn.  It just check whether the specified register can be zeroed for this target, for example, it will exclude stack register (st0 to st7), MMX registers (mm0 to mm7) and mask registers (t0 to t7) for X86 target from zeroing. 

The information depending on which return should be reflected in the data flow information,  which we can easily get from middle-end’s data flow analysis. 

I have added such target hook in the previous patch as: 

https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550018.html <https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550018.html>

However, I got several comments on too much target specific details exposed unnecessary in the very beginning of the discussion. 

However, If we want to add a default implementation in the middle end as Richard suggested, this target hook might be necessary.

Qing

> 
> 
> Segher



More information about the Gcc-patches mailing list