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)?
> As far as the register allocator issue. I wouldsuggest you look deeper
> into that since it could be either a register allocator bug or a bug in the
> backend. I suggest first looking at the state after IRA to see if it is
> sensible. If avr is still a reload target, note that we have a known bug
> with how reload handles paradoxical subregs that we're still working on.
The issue with the current PR was code like *(R28:HI + off) = R26:SI which can
be handled by avr.cc, but the asm out function was bogus and used %2 in
output_asm_insn() which was undefined, hence segmentation fault.
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.
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).
> 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?
