Richard Biener <richard.guent...@gmail.com> writes: > On Wed, Aug 11, 2021 at 11:28 AM Richard Sandiford > <richard.sandif...@arm.com> wrote: >> >> Richard Biener <richard.guent...@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.
Sounds good to me. Thanks, Richard
