> On Aug 28, 2020, at 2:47 AM, Alexandre Oliva <ol...@adacore.com> wrote:
>
> On Aug 26, 2020, Qing Zhao <qing.z...@oracle.com> wrote:
>
>> 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;
>
> Yeah, a target hook whose default is the generic code, and that targets
> that need it, or that benefit from it, can override. That's the point
> of hooks, to enable overriding. Why should this be an issue?
A default handler will be invoked for all the targets. So, if the target does
not provide any
target-specific handler to override it. The default handler should be correct
on this target.
So, the default handler should be correct on all the targets assuming no
override happening.
Correct me if I am wrong with the above understanding.
Then, for example, for the 32 bit hpux, is a default handler without any
special target handling
correct on it? My understanding from the previous discussion is, we need some
special handling
On 32 bit hpux to make it correct, So, in order to make the default handler
correct on 32 bit hpux,
We need to add another target hook, for example, targetm.has_return_stubs() to
check whether
A target has such feature, then in the default handler, we can call this new
target hook to check and
Then make sure the default handler is correct on 32 bit hpux.
There might be other targets that might need other special handlings which we
currently don’t know
Yet. Do we need to identify all those targets and all those special features,
and then add new
Target hook for each of the identified special feature?
Yes, theoretically, it’s doable to run testing on all the targets and to see
which targets need special
Handling and what kind of special handling we need, however, is doing this
really necessary?
>
>> 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.
>
> Why won't a naked USE pattern do? We already issue those in generic
> code, for regs holding return values. If we were to pretend that other
> registers are also holding zeros as values to be returned, why shouldn't
> that work for them as well?
From the current implementation based on X86, I see the following comments:
;; As USE insns aren't meaningful after reload, this is used instead
;; to prevent deleting instructions setting registers for PIC code
(define_insn "pro_epilogue_use"
[(unspec_volatile [(match_operand 0)] UNSPECV_PRO_EPILOGUE_USE)]
My understanding is, the “USE” will not be useful after reload. So a new
“pro_eplogue_use” should
be added.
HongJiu, could you please provide more information on this?
Thanks.
Qing
>
> --
> Alexandre Oliva, happy hacker
> https://urldefense.com/v3/__https://FSFLA.org/blogs/lxo/__;!!GqivPVa7Brio!NzNvCeA4fLoYPOD4RHTzKJd3QtgXG8bY2zXVcztQohMQRn5yROpYDp9CRbjjtcRV$
>
> Free Software Activist
> GNU Toolchain Engineer
