On Wed, Jan 11, 2023 at 07:38:44PM -0500, Paul Koning wrote:
> > On Jan 11, 2023, at 2:52 PM, Segher Boessenkool
> > <seg...@kernel.crashing.org> wrote:
> > On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote:
> > Before reload it did not have operands[0] and operands[1] the same,
> > already?
>
> No, and given that it's an addhi3 pattern that is fine before reload. It's
> reload that has to make them match because the machine instruction is two
> operand.
Sure. And one here is a pseudo, so it actually *can* reasonably be
tied.
> Indeed. So does that mean the discussion about insn 48 is the interesting
> one? That goes on for a while:
No, the insns 49 one is the useful one.
2 Non-pseudo reload: reject+=2
2 Non input pseudo reload: reject++
alt=0,overall=9,losers=1,rld_nregs=1
alt=1,overall=0,losers=0,rld_nregs=0
1 Matching alt: reject+=2
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=0,overall=11,losers=1 -- refuse
1 Matching alt: reject+=2
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=1,overall=11,losers=1 -- refuse
0 Spill pseudo into memory: reject+=3
Using memory insn operand 0: reject+=3
0 Non input pseudo reload: reject++
alt=2,overall=13,losers=1 -- refuse
0 Spill pseudo into memory: reject+=3
Using memory insn operand 0: reject+=3
0 Non input pseudo reload: reject++
alt=3,overall=13,losers=1 -- refuse
Choosing alt 1 in insn 49: (0) rR (1) 0 (2) Qi {addhi3}
For all four constraints it could tie operands[1] to it got "refuse".
This can't be good.
> > Please show *all* relevant things in the reload dump file? Everything
> > about insn 49 or any insn added to reload it, for example.
>
> I didn't see anything added to 49, but I'm not sure if I would necessarily
> recognize it. One observation is that the previous and next insns numbers
> are 48 and 53 in the IRA and Reload dumps both.
It would look like e.g.
Inserting insn reload before:
413: r179:SI=r25:SI
or
Inserting insn reload after:
414: r45:SI=r179:SI
> Attached is a .i file produced from the failing compile, with unneeded parts
> removed. It's not really tiny but not all that large. It consistently shows
> the failure using a pdp11-aout targeted GCC built from yesterday's code, when
> using -O2 or -Os and -mlra. It doesn't fail with -O1 or if -mlra is omitted
> (defaulting, in the currently committed code, to old reload).
It helped, I can reproduce the problem. Thanks!
Open a PR for the problem? So that people can cooperate on it easier,
and to battle the "attention span of a goldfish" problem?
Segher
