[Bug target/116587] New: ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[Bug target/116587] New: ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[zsojka at seznam dot cz]

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

            Bug ID: 116587
           Summary: ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868
                    (unable to find a register to spill)
                    {*andndi3_doubleword_bmi} with custom flags
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

Created attachment 59045
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59045&action=edit
reduced testcase

This needs a lot of custom flags to reproduce; this looks similar to PR113048,
so it might be useful to someone having a look at that PR:

$ x86_64-pc-linux-gnu-gcc -O2 -fPIC -mstackrealign -mavx512f
-fharden-control-flow-redundancy -fno-omit-frame-pointer -m32 -mbmi
-fkeep-gc-roots-live testcase.c
testcase.c: In function 'h':
testcase.c:24:1: error: unable to find a register to spill
   24 | }
      | ^
testcase.c:24:1: error: this is the insn:
(insn 281 402 438 5 (parallel [
            (set (reg:DI 477 [360])
                (and:DI (not:DI (reg/v:DI 368 [orig:227 d ] [227]))
                    (mem:DI (plus:SI (reg:SI 443)
                            (reg:SI 444 [orig:158 ivtmp.69 ] [158])) [2
MEM[(long long unsigned int *)i_16(D) + ivtmp.69_139 * 1]+0 S8 A32])))
            (clobber (reg:CC 17 flags))
        ]) "testcase.c":11:8 806 {*andndi3_doubleword_bmi}
     (expr_list:REG_DEAD (reg:SI 443)
        (expr_list:REG_DEAD (reg:SI 444 [orig:158 ivtmp.69 ] [158])
            (expr_list:REG_DEAD (reg/v:DI 368 [orig:227 d ] [227])
                (expr_list:REG_UNUSED (reg:CC 17 flags)
                    (nil))))))
during RTL pass: reload
testcase.c:24:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1868
0x2be6f8e internal_error(char const*, ...)
        /repo/gcc-trunk/gcc/diagnostic-global-context.cc:492
0xe745d5 fancy_abort(char const*, int, char const*)
        /repo/gcc-trunk/gcc/diagnostic.cc:1658
0x830947 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        /repo/gcc-trunk/gcc/rtl-error.cc:108
0x139bd2d lra_split_hard_reg_for()
        /repo/gcc-trunk/gcc/lra-assigns.cc:1868
0x13953c8 lra(_IO_FILE*, int)
        /repo/gcc-trunk/gcc/lra.cc:2521
0x134335f do_reload
        /repo/gcc-trunk/gcc/ira.cc:5976
0x134335f execute
        /repo/gcc-trunk/gcc/ira.cc:6164
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug rtl-optimization/116587] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org
          Component|target                      |rtl-optimization

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Cc added.

[Bug rtl-optimization/116587] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |jakub at gcc dot gnu.org
   Last reconfirmed|                            |2024-09-04
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
It looks to me that we have to apply the cure for PR114810 [1] also for the
split out (&r,r,o) alternative. That is, we should disable it for x86_32 by
using:

[(set_attr "isa" "x64,x64,*,*")])

or simply merge back alternative 2 with alternative 1.

x86_32 gets out of registers for (&r,r,o) alternative also with (offsetable)
memory address, where memory address can use up to two registers.

[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=628c2221d387

[Bug rtl-optimization/116587] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ubizjak at gmail dot com
             Status|NEW                         |ASSIGNED

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
Created attachment 59048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59048&action=edit
Proposed patch

> or simply merge back alternative 2 with alternative 1.
Yep, this works.

[Bug target/116587] [14/15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE: in                     |[14/15 Regression] ICE: in
                   |lra_split_hard_reg_for, at  |lra_split_hard_reg_for, at
                   |lra-assigns.cc:1868 (unable |lra-assigns.cc:1868 (unable
                   |to find a register to       |to find a register to
                   |spill)                      |spill)
                   |{*andndi3_doubleword_bmi}   |{*andndi3_doubleword_bmi}
                   |with custom flags           |with custom flags
          Component|rtl-optimization            |target
   Target Milestone|---                         |14.3

[Bug target/116587] [14/15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But in that case, why doesn't LRA consider simply forcing the complex memory
address into a single register and with that needing one less register?
&r,ro,r or &r,r,ro is something that happens in various places, not just in
this pattern.
E.g. *adddi3_doubleword, *adddi3_doubleword_zext (that one even has &r,rm,r),
...

[Bug target/116587] [14/15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #4)
> But in that case, why doesn't LRA consider simply forcing the complex memory
> address into a single register and with that needing one less register?
> &r,ro,r or &r,r,ro is something that happens in various places, not just in
> this pattern.
> E.g. *adddi3_doubleword, *adddi3_doubleword_zext (that one even has &r,rm,r),
> ...

Hm, surprisingly, the compiler now works with (&r,r,ro) [revert of the patch
from PR114810], including g++.target/i386/pr114810.C testcase.

[Bug target/116587] [14/15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #4)
> E.g. *adddi3_doubleword, *adddi3_doubleword_zext (that one even has &r,rm,r),
> ...
This one is not the problematic one since "m" is with word-mode operand. But
the last alternative (&r,r,m) can cause problems, "m" with double-word-mode
operand should be "o".

[Bug target/116587] [14/15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the m vs. o, there are quite a few (grepped just for the :TI cases because
:DI doesn't necessarily mean double-word):
grep 'match_operand:TI . ([^)]*).*m' tmp-mddump.md 
        (set (match_operand:TI 0 ("nonimmediate_operand") ("=!r ,o ,v,v ,v
,m,?jc,?Yd"))
            (match_operand:TI 1 ("general_operand")
("riFo,re,C,BC,vm,v,Yd,jc")))
            (plus:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
("r,m,r,m"))
            (ior:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
("r,m,r,m"))
            (xor:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
("r,m,r,m"))
            (plus:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
("r,m,r,m"))
            (ior:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
("r,m,r,m"))
            (xor:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
("r,m,r,m"))
                (match_operand:TI 1 ("nonimmediate_operand") ("0,0,r,m"))))
        (set (match_operand:TI 0 ("nonimmediate_operand") ("=xjm,vm"))
        (set (match_operand:TI 0 ("nonimmediate_operand") ("=vm"))
                    (match_operand:TI 1 ("memory_operand") ("+m"))
Though, maybe some of that is ok if it uses SSE loads/stores (e.g. the first
*movti_internal).
The others are
*insvti_highpart_1, *insvti_lowpart_1, *addti3_doubleword_zext,
*vec_extractv2ti (ok),
*vec_extractv4ti (ok), atomic_compare_and_swapti_doubleword (ok).

[Bug target/116587] [14/15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the :DI !TARGET_64BIT, perhaps *insvdi_lowpart_1, *adddi3_doubleword_zext,
*adddi3_doubleword_concat, *adddi3_doubleword_concat_zext

[Bug target/116587] [14/15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|ubizjak at gmail dot com           |unassigned at gcc dot gnu.org

[Bug target/116587] [14/15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #8)
> For the :DI !TARGET_64BIT, perhaps *insvdi_lowpart_1,
> *adddi3_doubleword_zext, *adddi3_doubleword_concat,
> *adddi3_doubleword_concat_zext

*_concat_* should be OK, DWIH means "half of DWI mode", so "m" is OK there.
Additional pattern with the "m" instead of "o" for double-width mode is
*addv<dwi>4_doubleword_1, but we have to use "jO" instad of "jM".

I'll prepare a patch for this part.

[Bug target/116587] [14/15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with custom flags

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #7)
> For the m vs. o, there are quite a few (grepped just for the :TI cases
> because :DI doesn't necessarily mean double-word):
> grep 'match_operand:TI . ([^)]*).*m' tmp-mddump.md 
>         (set (match_operand:TI 0 ("nonimmediate_operand") ("=!r ,o ,v,v ,v
> ,m,?jc,?Yd"))
>             (match_operand:TI 1 ("general_operand")
> ("riFo,re,C,BC,vm,v,Yd,jc")))
This is *movti_internal with store from xmm reg.
>             (plus:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
> ("r,m,r,m"))
>             (ior:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
> ("r,m,r,m"))
>             (xor:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
> ("r,m,r,m"))
These are *insvti_highpart_1, these use gen_lowpart on the memory operand,
gen_lowpart should work OK on non-offsetable memory.
>             (plus:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
> ("r,m,r,m"))
>             (ior:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
> ("r,m,r,m"))
>             (xor:TI (and:TI (match_operand:TI 1 ("nonimmediate_operand")
> ("r,m,r,m"))
These are *insvti_lowpart_1, these use gen_highpart, and should be fixed.
>                 (match_operand:TI 1 ("nonimmediate_operand") ("0,0,r,m"))))
*addti3_doubleword_zext, just fixed.
>         (set (match_operand:TI 0 ("nonimmediate_operand") ("=xjm,vm"))
*vec_extractv2ti, OK.
>         (set (match_operand:TI 0 ("nonimmediate_operand") ("=vm"))
*vec_extractv4ti, OK.
>                     (match_operand:TI 1 ("memory_operand") ("+m"))
cmpxchg16b, OK.

So, the only problem is with *insvti_lowpart_1.

I'll prepare a patch for this.