[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