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

H.J. Lu hjl.tools@gmail.com
Fri Aug 28 15:33:47 GMT 2020


On Fri, Aug 28, 2020 at 8:22 AM Qing Zhao <QING.ZHAO@oracle.com> wrote:
>
>
>
> > On Aug 28, 2020, at 2:47 AM, Alexandre Oliva <oliva@adacore.com> wrote:
> >
> > On Aug 26, 2020, Qing Zhao <qing.zhao@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?

pro_epilogue_use is needed.  Otherwise, these zeroing instructions
will be removed after reload.

-- 
H.J.


More information about the Gcc-patches mailing list