Re: LRA produces RTL not meeting constraint

[Segher Boessenkool <segher@kernel.crashing.org>]

On Wed, Jan 11, 2023 at 07:38:44PM -0500, Paul Koning wrote:
> > On Jan 11, 2023, at 2:52 PM, Segher Boessenkool <segher@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