> On Aug 26, 2020, at 7:02 AM, Alexandre Oliva <ol...@adacore.com> wrote:
>
> On Aug 25, 2020, Jeff Law <l...@redhat.com <mailto:l...@redhat.com>> wrote:
>
>> On Tue, 2020-08-25 at 02:16 -0300, Alexandre Oliva wrote:
>>> On Aug 24, 2020, Richard Biener <rguent...@suse.de> wrote:
>>>
>>>> since the option is quite elaborate on what (sub-)set of regs is
>>>> supposed to be cleared I'm not sure an implementation not involving
>>>> any target hook is possible?
>>>
>>> I don't think this follows. Machine-independent code has a pretty good
>>> notion of what registers are call-saved or call-clobbered, which ones
>>> could be changed in this regard for function-specific calling
>>> conventions, which ones may be used by a function to hold its return
>>> value, which ones are used within a function...
>>>
>>> It *should* be possible to introduce this in machine-independent code,
>>> emitting insns to set registers to zero and regarding them as holding
>>> values to be returned from the function. Machine-specific code could
>>> use more efficient insns to get the same result, but I can't see good
>>> reason to not have a generic fallback implementation with at least a
>>> best-effort attempt to offer the desired feature.
>> I think part of the problem here is you have to worry about stubs which can
>> change caller-saved registers. Return path stubs aren't particularly
>> common, but
>> they do exist -- 32 bit hpux for example :(
>
> This suggests that such targets might have to implement the
> target-specific hook to deal with this, but does it detract in any way
> from the notion of having generic code to fall back to on targets that
> do NOT require any special handling?
There are two issues I can see with adding a default generator in middle end:
1. In order to determine where a target should not use the generic code to emit
the zeroing sequence,
a new target hook to determine this has to be added;
2. In order to avoid the generated zeroing insns (which are simply insns that
set registers) being deleted,
We have to define a new insn “pro_epilogue_use” in the target.
So, any target that want to use the default generator in middle end, must
provide such a new target hook.
Based on the above 2, I don’t think that adding the default generator in middle
end is a good idea.
Qing
>
> --
> Alexandre Oliva, happy hacker
> https://urldefense.com/v3/__https://FSFLA.org/blogs/lxo/__;!!GqivPVa7Brio!Pee3_l4yYpNOUbnymMqrEM68oDGk-2Q3zebqLnQ255SX5go78t8Sq1RmM72wJP3a$
>
> <https://urldefense.com/v3/__https://FSFLA.org/blogs/lxo/__;!!GqivPVa7Brio!Pee3_l4yYpNOUbnymMqrEM68oDGk-2Q3zebqLnQ255SX5go78t8Sq1RmM72wJP3a$>
>
> Free Software Activist
> GNU Toolchain Engineer