[committed][rtl-optimization/116244] Don't create bogus regs in alter_subreg
Jeff Law
jeffreyalaw@gmail.com
Sat Feb 8 22:51:43 GMT 2025
On 2/8/25 1:52 PM, Georg-Johann Lay wrote:
>
>
> Am 08.02.25 um 18:23 schrieb Jeff Law:
>>
>>
>> On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
>>
>>>
>>> That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?
>>> id=116389#c7
>>> still ICEs with that change in http://gcc.gnu.org/r15-7428
>>>
>>> pr116389-red.c: In function 'func':
>>> pr116389-red.c:20:1: error: insn does not satisfy its constraints:
>>> 20 | }
>>> | ^
>>> (insn 27 69 28 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
>>> (const_int 2 [0x2])) [4 %sfp+2 S4 A8])
>>> (reg:SI 30 r30)) "pr116389-red.c":16:19 146 {*movsi_split}
>>> (nil))
>>> during RTL pass: postreload
>>> pr116389-red.c:20:1: internal compiler error: in
>>> extract_constrain_insn, at recog.cc:2783
>>>
>>> Reason is that R30 is the last GPR and can hold HImode at most,
>>> but due to a paradoxical subreg, there is r30:SI.
>> Bummer as that was the kind of scenario it's supposed to fix.
>>
>> What did that insn look like before IRA and for whatever pseudo was in
>> that operand, what hard register did IRA think it should be allocated to?
>>
>> jeff
>
> The .ira dump has several paradoxical subregs like:
>
> (insn 22 21 60 4 (set (reg/v:SI 51 [ val32 ])
> (subreg:SI (reg:HI 53 [ t$val ]) 0)) "pr116389-red.c":14:14 146
> {*movsi_split}
>
> (insn 27 26 28 5 (set (reg/v:SI 51 [ val32 ])
> (subreg:SI (reg/v:HI 52 [ diff ]) 0)) "pr116389-red.c":16:19
> 146 {*movsi_split}
>
> (insn 35 34 36 7 (set (reg:HI 54 [ _7 ])
> (ashift:HI (subreg:HI (reg/v:SI 51 [ val32 ]) 0)
> (const_int 1 [0x1]))) "pr116389-red.c":18:13 667 {ashlhi3}
>
> I don't know which one is causing the trouble. Maybe the attached
> dumps will help.
I would suggest looking at the .IRA dump. You want to know what
register was assigned to pseudo 52. I'm guessing it'll be r30, at which
point you'll probably want to debug the same code I just changed to
figure out why it's not working in the expected manner.
jeff
More information about the Gcc-patches
mailing list