PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]
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 <firstname.lastname@example.org> wrote:
> > On Aug 26, 2020, Qing Zhao <email@example.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.
More information about the Gcc-patches