> On Sep 11, 2020, at 12:13 PM, Segher Boessenkool <seg...@kernel.crashing.org>
> wrote:
>
> On Fri, Sep 11, 2020 at 11:52:29AM -0500, Qing Zhao wrote:
>> I don’t understand why it’s not correct if we clearing call-clobbered
>> registers
>> AFTER restoring call-preserved registers?
>
> Because the compiler backend (or the linker! Or the dynamic linker!
> Etc.) can use volatile registers for their own purposes.
For the following sequence at the end of a routine:
*...*
“restore call-preserved registers”
*clear call-clobbered registers"*
*ret*
“Clear call-clobbered registers” will only clear the call-clobbered registers
that are not live at the end of the routine.
If the call-clobbered register is live at the end of the routine, for example,
holding the return value,
It will NOT be cleared at all.
If the call-clobbered register has some other usage after the routine return,
then the backend should know this and will not
clear it. Then we will resolve this issue, right?
>
> Like, on Power, r11 and r12 are used for various calling convention
> purposes; they are also used for other purposes; and r0 is used as some
> all-purpose volatile (it typically holds the return address near the
> end of a function).
In the new version of the patch, the implementation of clearing call-clobbered
registers is done in backend, middle end only
computes a hard register set based on user option, source attribute, data flow
information, and function abi information, and
Then pass this hard register set to the target hook to generate the clearing
sequence. The backend will have all the details
on the special situations you mentioned.
Let me know any more concerns here.
thanks.
Qing
>
> "Call-clobbered" is pretty meaningless. It only holds meaning for a
> function calling another, and then only to know which registers lose
> their value then. It has no semantics for other cases, like a function
> that will return soonish, as here.
>
>
> Segher
