On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> On Tue, Dec 03, 2019 at 10:33:48PM +0900, Oleg Endo wrote:
> > On Mon, 2019-11-25 at 16:47 -0600, Segher Boessenkool wrote:
> > >
> > > > > - sh (that's sh4-linux):
> > > > >
> > > > > /home/segher/src/kernel/net/ipv4/af_inet.c: In function
> > > > > 'snmp_get_cpu_field':
> > > > > /home/segher/src/kernel/net/ipv4/af_inet.c:1638:1: error: unable to
> > > > > find a register to spill in class 'R0_REGS'
> > > > > 1638 | }
> > > > > | ^
> > > > > /home/segher/src/kernel/net/ipv4/af_inet.c:1638:1: error: this is the
> > > > > insn:
> > > > > (insn 18 17 19 2 (set (reg:SI 0 r0)
> > > > > (mem:SI (plus:SI (reg:SI 4 r4 [178])
> > > > > (reg:SI 6 r6 [171])) [17 *_3+0 S4 A32]))
> > > > > "/home/segher/src/kernel/net/ipv4/af_inet.c":1638:1 188 {movsi_i}
> > > > > (expr_list:REG_DEAD (reg:SI 4 r4 [178])
> > > > > (expr_list:REG_DEAD (reg:SI 6 r6 [171])
> > > > > (nil))))
> > > > > /home/segher/src/kernel/net/ipv4/af_inet.c:1638: confused by earlier
> > > > > errors, bailing out
> > > >
> > > > Would have to look more at this one. Seems odd that it can't allocate
> > > > R0 when it's already the destination and when R0 can't be live before
> > > > the insn. But there again, this is reload, so my enthuasiasm for
> > > > looking
> > > > is a bit limited :-)
> > >
> > > It wants to use r0 in some other insn, so it needs to spill it here, but
> > > cannot. This is what class_likely_spilled is for.
> >
> > Hmm ... the R0 problem ... SH doesn't override class_likely_spilled
> > explicitly, but it's got a R0_REGS class with only one said reg in it.
> > So the default impl of class_likely_spilled should do its thing.
>
> Yes, good point. So what happened here?
"Something, somewhere, went terribly wrong"...
insn 18 wants to do
mov.l @(r4,r6),r0
But it can't because the reg+reg address mode has a R0 constraint
itself. So it needs to be changed to
mov r4,r0
mov.l @(r0,r6),r0
And it can't handle that. Or only sometimes? Don't remember.
> Is it just RA messing things
> up, unrelated to the new pass?
>
Yep, I think so. The additional pass seems to create "tougher" code so
reload passes out earlier than usual. We've had the same issue when
trying address mode selection optimization. In fact that was one huge
showstopper.
Cheers,
Oleg
