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

Reply via email to