[PATCH] Adding target hook allows to reject initialization of register

Richard Biener richard.guenther@gmail.com
Wed Aug 11 10:43:56 GMT 2021


On Wed, Aug 11, 2021 at 11:28 AM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Richard Biener <richard.guenther@gmail.com> writes:
> > On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >> Some target like RISC-V allow to group vector register as a whole,
> >> and only operate part of it in fact, but the 'init-regs' pass will add initialization
> >> for uninitialized registers. Add this hook to reject this action for reducing instruction.
> >
> > Are these groups "visible"?  That is, are the pseudos multi-reg
> > pseudos?  I wonder
> > if there's a more generic way to tame down initregs w/o introducing a new target
> > hook.
> >
> > Btw, initregs is a red herring - it ideally should go away.  See PR61810.
> >
> > So instead of adding to it can you see whether disabling the pass for RISC-V
> > works w/o fallout (and add a comment to the PR)?  Maybe some more RTL
> > literate (in particular DF literate) can look at the remaining issue.
> > Richard, did you
> > ever have a look into the "issue" that initregs covers up (whatever
> > that exactly is)?
>
> No, sorry.  I don't really understand what it would be from the comment
> in the code:
>
>    [...] papers over some problems on the arm and other
>    processors where certain isa constraints cannot be handled by gcc.
>    These are of the form where two operands to an insn my not be the
>    same.  The ra will only make them the same if they do not
>    interfere, and this can only happen if one is not initialized.
>
> That would definitely be an RA bug if true, since the constraints need
> to be applied independently of dataflow information.  But the comment
> and code predate LRA and maybe no-one fancied poking around in reload
> (hard to believe).
>
> I'd be very surprised if LRA gets this wrong.

OK, we're wondering since quite some time - how about changing the
gate of initregs to optimize > 0 && !targetm.lra_p ()?  We'll hopefully
figure out the "real" issue the pass is papering over.  At the same time
we're leaving old reload (and likely unmaintianed) targets unaffected.

Richard.

> Thanks,
> Richard


More information about the Gcc-patches mailing list