https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116390
--- Comment #9 from Jeffrey A. Law <jeffreyalaw at gmail dot com> --- On 8/17/24 2:37 PM, gjl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116390 > > Georg-Johann Lay <gjl at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |gjl at gcc dot gnu.org > > --- Comment #8 from Georg-Johann Lay <gjl at gcc dot gnu.org> --- > (In reply to Jeffrey A. Law from comment #7) >> It has always been advantageous if (when safe) patterns that accept >> zero/sign extension could also accept a paradoxical subreg. With ext-dce it >> just make it even more useful to handle those cases. > I don't see how that would work, since extend has a different anatomy / rtx > type than a subreg (extend is "e" whilst subreg is "ep"). Hence this would > mean new patterns with subreg(s) instead of extend(s)? An appropriate match_operator can do this. > > While code like *(R28:HI + off) = R26:SI is silly, it can still be suppoprted. > This is different with PR116390 that has xxx = R30:SI which is invalid, > because > R30 can hold one byte, R31 can hold one byte, and there are no more hard regs > after that. Which again, the generic code generally knows how to handle, meaning the issue is most likely in the avr backend. > > As the transformations from ext-dce are supposed to be an optimization, the > sensible thing to do in the register allocator would be to only ever touch the > SUBREG_REG part of the subreg, i.e. only store (and allocate) HImode instead > of > the extended mode. (The patch for the current PR assumes that *(R28:HI + off) > = R26:SI originates from ext-dce and that the high 16 bits of R26:SI only > contain garbage, and hence don't require being written to the stack slot. But > the right place would be RA only touching / allocating the required bytes). Ideally the subregs get removed by tying the input and output together resulting in a nop copy. > >> note that we have a known bug with how reload handles paradoxical >> subregs that we're still working on. > IIUC PR116389 is a DUP of some other PR? Hard to know since the root cause hasn't been determined yet. jeff
