[Bug rtl-optimization/108388] New: LRA generates RTL that violates constraints

[Bug rtl-optimization/108388] New: LRA generates RTL that violates constraints

[pkoning at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388

            Bug ID: 108388
           Summary: LRA generates RTL that violates constraints
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pkoning at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54259
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54259&action=edit
Reproducer for this issue

In gcc for pdp11-aout, compiling with LRA enabled (-mlra) and optimization (-Os
or -O2) I get an ICE when building libgcc2.  The issue appears to be that LRA
first assigns a hard register for the destination of an addhi3 RTL,
specifically R5.  R5 is the frame register, but it can be eliminated.  The
source is an address computed from the frame pointer, i.e., a (plus (r5) (const
int something)).  The machine is a two-operand machine, so in patterns like
addhi3 the operand descriptor for operand 1 (first source) requires it to be
the same as operand 0 (destination).

So far so good.  The assigned register indeed satisfies that constraint.

But apparently after that point LRA decides to eliminate the frame register, so
it simply replaces that frame-related reference in the source by a stack
pointer based reference, of the form (plus (sp) (const int something-else)). 
At this point we have a constraint violation because operands 0 and 1 are now
different (r5 and sp respectively).  Correct code would require copying sp into
some other register then doing the addhi3 with that register.

The code compiles correctly with old reload (the default, in the currently
committed pdp11 target).

[Bug rtl-optimization/108388] LRA generates RTL that violates constraints

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388

--- Comment #1 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Thank you for reporting this.  I've been working on this PR.  I believe the PR
reveals the problem not only for PDP11.  I guess the same can happen for some
other targets.

I hope the patch will be ready the next week as it requires a good testing for
several major targets.  Unfortunately, practically any change in LRA might have
unexpected effect on other targets.

[Bug rtl-optimization/108388] LRA generates RTL that violates constraints

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Vladimir Makarov <vmakarov@gcc.gnu.org>:

https://gcc.gnu.org/g:265a749f290f7c6adc9a3aaa9c585b498a8a38ea

commit r13-5332-g265a749f290f7c6adc9a3aaa9c585b498a8a38ea
Author: Vladimir N. Makarov <vmakarov@redhat.com>
Date:   Tue Jan 24 16:10:59 2023 -0500

    LRA: Always do elimination and only for hard register to check insn
constraints

    LRA does elimination but not always checks insn constraints in this case.
    This results in LRA failure for PDP11 target whose addition is only 2-op
insn.
    The same might happen for other analogous targets.  The patch fixes this
problem.

            PR rtl-optimization/108388

    gcc/ChangeLog:

            * lra-constraints.cc (get_hard_regno): Remove final_p arg.  Always
            do elimination but only for hard register.
            (operands_match_p, uses_hard_regs_p, process_alt_operands): Adjust
            calls of get_hard_regno.

    gcc/testsuite/ChangeLog:

            * gcc.target/pdp11/pdp11.exp: New.
            * gcc.target/pdp11/pr108388.c: New.

[Bug rtl-optimization/108388] LRA generates RTL that violates constraints

[pkoning at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388

pkoning at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from pkoning at gcc dot gnu.org ---
Looks good.  I confirmed that pdp11 GCC with default LRA now builds properly,
and my standard test run of the GCC test suite (compile tests) looks good. 
Essentially the same pass/fail numbers (mostly pass, though I have work to do)
as in runs last year with reload as the default.