[Bug rtl-optimization/106419] New: ICE in lra_assign, at lra-assigns.cc:1649

[Bug rtl-optimization/106419] New: ICE in lra_assign, at lra-assigns.cc:1649

[asolokha at gmx dot com]

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

            Bug ID: 106419
           Summary: ICE in lra_assign, at lra-assigns.cc:1649
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, ra
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: powerpc-*-linux-gnu

gfortran 13.0.0 20220717 snapshot (g:7bcd7f47359b903bf7a193b95d4450d9d69c60ba)
ICEs when compiling the following testcase w/ -mcpu=e6500 -Og
-fmove-loop-invariants --param ira-max-conflict-table-size=0:

      SUBROUTINE SMLC09 (FOO, BAR, N, NFVALS, G, GOPT, GS, DDOTG,
     *     RELACC, STEP, F, X, XL, XS, XU)
      EXTERNAL FOO
      EXTERNAL BAR
      INTEGER N, NFVALS
      INTEGER I, NOBACK
      REAL G(*), GOPT(*), GS(*)
      REAL DDOTG, RELACC, STEP, F
      REAL X(*), XL(*), XS(*), XU(*)

      NOBACK = 0
 20   IF (NOBACK .NE. 0) GOTO 70

      NOBACK = 0
      X(1) = XS(1) + 2

      CALL FOO(G)
      CALL BAR(XL, XU, 0)

      IF (F .EQ. 0) THEN
         NOBACK = 1
         DO I = 1, N
            GOPT(I) = 0
            GS(I) = 0
         END DO
      END IF

      IF (NFVALS .EQ. 0.2) GOTO 70

      IF (DDOTG .EQ. 1) STEP = MIN(DTGLOW, RELACC)

      STEP = MAX(0.1, DDOTG / 2)
      GOTO 20

 70   RETURN
      END

% powerpc-e300c3-linux-gnu-gfortran-13.0.0 -mcpu=e6500 -Og
-fmove-loop-invariants --param ira-max-conflict-table-size=0 -c u3jg7f7h.f
during RTL pass: reload
u3jg7f7h.f:36:72:

   36 |       END
      |                                                                       
^
internal compiler error: in lra_assign, at lra-assigns.cc:1649
0xd2d717 lra_assign(bool&)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/lra-assigns.cc:1649
0xd275d4 lra(_IO_FILE*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/lra.cc:2426
0xcde5f9 do_reload
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/ira.cc:5940
0xcde5f9 execute
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/ira.cc:6126

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-07-25
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
                 CC|                            |linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
I wasn't able to reproduce this with cross build compiler w/i either latest
trunk or the mentioned snapshot.  I guess there might be some differences
between our configurations.

My configuration from by "-v": ... --target=powerpc-e300c3-linux-gnu
--enable-languages=c,c++,fortran --enable-obsolete --disable-werror
--with-system-zlib --disable-nls --disable-libunwind-exceptions
--enable-checking=yes --disable-esp --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-poison-system-directories
--with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
--disable-libada --disable-cet --disable-systemtap
--enable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --with-isl --disable-isl-version-check
--disable-libsanitizer --enable-default-pie --enable-default-ssp

Maybe one dump file from -mdebug=target (or =all) can help.

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha <asolokha at gmx dot com> ---
I don't set --enable-default-pie anymore when configuring gcc, so here's the
difference. Therefore, it stops ICEing if I add -fPIE or -fPIC when compiling
the testcase. Conversely, could you please try adding -fno-PIE?

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[linkw at gcc dot gnu.org]

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

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Arseny Solokha from comment #2)
> I don't set --enable-default-pie anymore when configuring gcc, so here's the
> difference. Therefore, it stops ICEing if I add -fPIE or -fPIC when
> compiling the testcase. Conversely, could you please try adding -fno-PIE?

Thanks for the reply.  Sigh, I am still unable to reproduce it. I tried to add
extra option "-fno-PIE", "-fno-PIE -fno-PIC", "-fno-pie -fno-pic", it still
passed. Same behaviors even if I removed the "--enable-default-pie" from
config, or explicitly added the "--disable-default-pie" into config.

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha <asolokha at gmx dot com> ---
Created attachment 53345
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53345&action=edit
-mdebug=target dump

--host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/13.0.0
--includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/13.0.0/include
--datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/13.0.0
--mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/13.0.0/man
--infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/13.0.0/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/13.0.0/include/g++-v13
--with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/13.0.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=yes --disable-esp
--enable-libstdcxx-time --disable-libstdcxx-pch
--enable-poison-system-directories --with-sysroot=/usr/powerpc-e300c3-linux-gnu
--disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libssp --disable-libada --disable-cet --disable-systemtap
--enable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --with-isl --disable-isl-version-check
--disable-libsanitizer --enable-default-ssp

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks for the configuration command and dump. By looking into them, I found
the difference is "--enable-secureplt", with one rebuilt cross binutils with
--enable-secureplt, I am able to reproduce this now.

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org,
                   |                            |vmakarov at gcc dot gnu.org

--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
>From the ICE point:

  if (! lra_hard_reg_split_p && ! lra_asm_error_p && flag_checking)
    /* Check correctness of allocation but only when there are no hard reg
       splits and asm errors as in the case of errors explicit insns involving
       hard regs are added or the asm is removed and this can result in
       incorrect allocation.  */
    for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
      if (lra_reg_info[i].nrefs != 0
          && reg_renumber[i] >= 0
          && overlaps_hard_reg_set_p (lra_reg_info[i].conflict_hard_regs,
                                      PSEUDO_REGNO_MODE (i), reg_renumber[i]))
        gcc_unreachable ();

this is similar to PR97978. I commented out the line gcc_unreachable(), the
resulted assembly looks fine to me. It's able to spill the value into one stack
slot, it's reloaded after the second indirect call (though the code is very
poor but it's at -Og).

        mr 3,14      // ctr doesn't conflict with r3
        mfctr 9
        mtctr 9
        stw 9,36(1)  // saved
        crxor 6,6,6
        bctrl
        mr 5,18
        lwz 7,160(1)
        mr 4,7
        lwz 6,152(1)
        mr 3,6
        lwz 12,28(1)
        mtctr 12
        crxor 6,6,6
        bctrl
        lfs 0,.LC2@l(31)
        lfs 12,0(24)
        fcmpu 0,12,0
        lwz 12,28(1)
        lwz 6,152(1)
        lwz 7,160(1)
        lwz 9,36(1)  // reload
        mtctr 9      // make it live in ctr

IMHO, this is very likely a LRA issue, maybe the assert condition is too
strict.

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
That mfctr;mtctr is extremely slow of course, and that mtctr is superfluous
completely (this is true for all registers, not just CTR, nothing special to
PowerPC even).  I know this is just -Og, but still :-)

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> ---
So for which pseudo and which hard register did this ICE, and what did the
code look like at that point?

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[linkw at gcc dot gnu.org]

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

--- Comment #9 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #8)
> So for which pseudo and which hard register did this ICE, and what did the
> code look like at that point?

The culprit pseudo is r133, the values of those related expressions in the
check:

lra_reg_info[i].nrefs  -> 4

reg_renumber[i] -> 97

overlaps_hard_reg_set_p(lra_reg_info[i].conflict_hard_regs, E_SImode, 97) ->
true

Before IRA, the code looks like:

(note 21 1 166 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 166 21 2 2 (set (reg:SI 229)
        (reg:SI 3 3 [ foo ])) "test.f":1:23 562 {*movsi_internal1}
     (expr_list:REG_DEAD (reg:SI 3 3 [ foo ])
        (nil)))
(insn 2 166 167 2 (set (reg/v/f:SI 133 [ foo ])
        (reg:SI 229)) "test.f":1:23 562 {*movsi_internal1}
     (expr_list:REG_DEAD (reg:SI 229)
        (nil)))
....

(insn 33 32 34 4 (set (reg:SI 3 3)
        (reg/v/f:SI 137 [ g ])) "test.f":17:72 562 {*movsi_internal1}
     (nil))
(insn 34 33 35 4 (set (reg:SI 97 ctr)
        (reg/v/f:SI 133 [ foo ])) "test.f":17:72 562 {*movsi_internal1}
     (nil))      
(call_insn 35 34 38 4 (parallel [
            (call (mem:SI (reg:SI 97 ctr) [0 *foo_21(D) S4 A8])
                (const_int 0 [0]))
            (use (const_int 4 [0x4]))
            (clobber (reg:SI 96 lr))
        ]) "test.f":17:72 814 {*call_indirect_nonlocal_sysvsi}
     (expr_list:REG_DEAD (reg:SI 97 ctr)
        (expr_list:REG_DEAD (reg:SI 3 3)
            (nil)))
    (expr_list:SI (use (reg:SI 3 3))
        (nil)))

...

in IRA, the hard reg assignment is:

  125:r120 l0     9   86:r125 l0    10   13:r126 l0    29   87:r127 l0     8
   73:r128 l0    44   35:r133 l0     3   33:r134 l0     4   31:r135 l0     0
  ...

choosing r3 for r133.  As above, the r3 is redefined at insn 33, r133 is used
in insn34, so it has to try to split the live range of r133.

I didn't dig into LRA code, I don't really understand what the condition means.
:( The reason why I did the hacking by commenting gcc_unreachable() is to see
how it causes some unexpected consequence without this kind of checking. As
shown above, the resulted assembly looks inefficient, but it should work from
correctness perspective. So I guessed maybe the condition is too strict or we
miss to consider something special and punt some valid things.

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > So for which pseudo and which hard register did this ICE, and what did the
> > code look like at that point?
> 
> The culprit pseudo is r133, the values of those related expressions in the
> check:
> 
> lra_reg_info[i].nrefs  -> 4
> 
> reg_renumber[i] -> 97
> 
> overlaps_hard_reg_set_p(lra_reg_info[i].conflict_hard_regs, E_SImode, 97) ->
> true
> 
> Before IRA, the code looks like:

> (insn 34 33 35 4 (set (reg:SI 97 ctr)
>         (reg/v/f:SI 133 [ foo ])) "test.f":17:72 562 {*movsi_internal1}
>      (nil))      

> in IRA, the hard reg assignment is:

> choosing r3 for r133.

Doing ctr (reg 97) instead (as LRA seems to change it to?) is
counterproductive.

We have that

> (insn 33 32 34 4 (set (reg:SI 3 3)
>         (reg/v/f:SI 137 [ g ])) "test.f":17:72 562 {*movsi_internal1}
>      (nil))

right before 34, so if we want to use hard reg 3 for pseudo 97 we could
swap insns 33 and 34 (both of which are trivial assignments), much nicer
than the current dance via memory.

But all of this is a distraction from the actual bug here, sorry.