On 2/9/25 1:10 AM, Georg-Johann Lay wrote:
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
That subreg handling in ira-build.c triggers 3 times:
create_insn_allocnos[func:ira(324)]: outer=(subreg:HI (reg/v:SI 51
[ val32 ]) 0)
create_insn_allocnos[func:ira(324)]: outer=(subreg:SI (reg/v:HI 52
[ diff ]) 0)
create_insn_allocnos[func:ira(324)]: outer=(subreg:SI (reg:HI 53
[ t$val ]) 0)
Insn 27 in the .ira dump reads:
(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}
(expr_list:REG_DEAD (reg/v:HI 52 [ diff ])
As far as I can see, IRA doesn't allocate a pseudo but expects a spill
for r52:
Allocno a3r52 of GENERAL_REGS(14) has 2 avail. regs 18-19, node: 18-19
obj 0 (confl regs = 0-17 20-36), obj 1 (confl regs = 0-17 20-36)
Pushing a3(r52,l0)(potential spill: pri=12000, cost=12000)
Popping a4(r53,l0) -- assign reg 18
Popping a3(r52,l0) -- spill
Popping a0(r54,l0) -- assign reg 24
Disposition:
1:r51 l0 mem 3:r52 l0 mem 4:r53 l0 18 0:r54 l0
24
6:r55 l0 20 8:r56 l0 24 7:r57 l0 24 5:r58 l0
24
2:r59 l0 24
And spill code generation is up to reload? .reload reads:
Yes. What this all says is that IRA is doing something sensible. So
the problem is reload or something in the avr port.
insn=27, live_throughout: 32, dead_or_set: 51, 52
Spilling for insn 27.
Using reg 20 for reload 1
Reloads for insn # 27
Reload 0: reload_out (SI) = (reg/v:SI 51 [ val32 ])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (reg/v:SI 51 [ val32 ])
Reload 1: reload_in (HI) = (reg/v:HI 52 [ diff ])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v:HI 52 [ diff ])
reload_reg_rtx: (reg:HI 30 r30)
(insn 69 26 27 5 (set (reg:HI 30 r30)
(mem/c:HI (plus:HI (reg/f:HI 28 r28)
(const_int 2 [0x2])) [4 %sfp+2 S2 A8])) "pr116389-
red.c":16:19 128 {*movhi_split}
(nil))
(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))
So it loads HI:30 from fp+2 and then pushes it as SI:30 to fp+2.
Insn 69 is generated by reload.
It seems reload is generating these insns to do a paradoxical
subreg in memory since it cannot be done in registers?
My working memory of reload is diminishing by the day, especially
anything related to subregs. I wouldn't necessarily make the assumption
that it cannot be done, it's more likely there just aren't enough
registers available at the right points. So the object gets forced into
memory irrespective of whether or not a paradoxical subreg is involved.
But that's speculation -- subreg handling in reload is nontrivial and
there may be places where it just gives up a generates reloads.
If someone wanted to chase down reload's behavior, I'd start with the
selection of r30 as the reload register. It makes sense in HImode, but
not when there's a outer paradoxical subreg at the use point.
jeff
Johann
