On Fri, Aug 28, 2020 at 8:22 AM Qing Zhao <qing.z...@oracle.com> wrote: > > > > > 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?
pro_epilogue_use is needed. Otherwise, these zeroing instructions will be removed after reload. -- H.J.
