[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3 since r15-1042-g68b0742a49d

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

Summary|[15 Regression] ICE in  |[15 Regression] ICE in
   |smallest_mode_for_size, at  |smallest_mode_for_size, at
   |stor-layout.cc:356 during   |stor-layout.cc:356 during
   |combine on RISC-V   |combine on RISC-V
   |rv64gcv_zvl256b at -O3  |rv64gcv_zvl256b at -O3
   ||since r15-1042-g68b0742a49d

--- Comment #5 from Patrick O'Neill  ---
Bisected to first bad commit: r15-1042-g68b0742a49d

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #4 from Patrick O'Neill  ---
This failure also appears when compiling glibc 2.39 with rv64gcv_zvl512b and
rv64gcv_zvl1024b.

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

[rdapp at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Robin Dapp  ---
At first it looked very weird that we need 50 (or so) instructions to expand

;; MEM  [(short int *)] = vect_cst__21;

but then I realized that all the hoops we jump through are due to possible
misalignment.  Otherwise we could of course just emit a vector store.

So we don't ICE with -mno-vector-strict-align.

Going to look into the actual issue in the next days.

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
Note in most cases `(subreg:DI (reg:V16HI 139 [ vect_cst__21 ]) 0) (const_int
16 [0x10])` would normally be a `vec_select` so I am shock that it is using a
subreg here ...

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-14

--- Comment #1 from Andrew Pinski  ---
Trying 25 -> 26:
   25: r150:DI=r139:V16HI#0 0>>0x10
   26: r151:DI=zero_extend(r150:DI#0)

That is these 2 instructions:
```
(insn 25 24 26 2 (set (reg:DI 150)
(lshiftrt:DI (subreg:DI (reg:V16HI 139 [ vect_cst__21 ]) 0)
(const_int 16 [0x10]))) "/app/example.c":5:14 299 {lshrdi3}
 (nil))
(insn 26 25 34 2 (set (reg:DI 151)
(zero_extend:DI (subreg:HI (reg:DI 150) 0))) "/app/example.c":5:14 121
{*zero_extendhidi2}
 (expr_list:REG_DEAD (reg:DI 150)
(nil)))
```
The above rtl looks good as far as I know. It looks like
get_best_extraction_insn is using V16HI there though which is where it goes
wrong.

Confirmed.

This comes from the expanision of:
;; MEM  [(short int *)] = vect_cst__21;

Which looks different for GCC 14.1.0 and much simplier.

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 CC||pinskia at gcc dot gnu.org
  Component|middle-end  |rtl-optimization