[Bug target/116953] [avr] error: operands to %T/%t must be reg + const_int

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |14.3

--- Comment #3 from Georg-Johann Lay  ---
Fixed in v14.3+.

[Bug target/116953] New: [avr] error: operands to %T/%t must be reg + const_int

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

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

Bug ID: 116953
   Summary: [avr] error: operands to %T/%t must be reg + const_int
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

unsigned foo (unsigned x, unsigned y)
{
  int i;
  for (i = 8; i--; x <<= 1)
y ^= (x ^ y) & 0x80 ? 79U : 0U;
  return y;
}

$ avr-gcc -S -O2 -mmcu=atmega128 ...
bug.c: In function 'foo':
bug.c:7:1: error: operands to %T/%t must be reg + const_int:
7 | }
  | ^
(const_int 79 [0x4f])
during RTL pass: final
bug.c:7:1: internal compiler error: in avr_print_operand, at
config/avr/avr.cc:2593
0xdec976 avr_print_operand
../../../source/gcc-master/gcc/config/avr/avr.cc:2593
0x6edc19 output_operand(rtx_def*, int)
../../../source/gcc-master/gcc/final.cc:3632
0x6ed73c output_asm_insn(char const*, rtx_def**)
../../../source/gcc-master/gcc/final.cc:3525
0xe058ad avr_out_sbxx_branch(rtx_insn*, rtx_def**)
../../../source/gcc-master/gcc/config/avr/avr.cc:13651
0x6ea2f6 get_insn_template(int, rtx_insn*)
../../../source/gcc-master/gcc/final.cc:2027
0x6ebea9 final_scan_insn_1

The bug works as follows:

avr.cc::avr_out_sbxx_branch() calls jump_over_one_insn_p() to determine whether
the current insn may skip the next instruction. jump_over_one_insn_p() uses
avr_2word_insn_p() on the NEXT insn, in particular it might compute insn
attributes to determine whether the next insn is a single instruction.
Computing insn attributes may run extract, which sets recog_data.operand
according to the next insn, but avr_out_sbxx_branch() assumes that operands
still holds operands for the current insn.

The probability for this bug increased with r15-3634, but it may also occur
without it.

Depending on the (operands of) the next insn, the ICE diagnostic may be
different, or wrong code may be generated, or a different ICE may trigger like
a segmentation fault.

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #11 from Georg-Johann Lay  ---
There's PR116778 that also produces wrong code; maybe it's the same issue --
but easier to analyse.  At least for that PR the bad insn is already known.

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #9 from Georg-Johann Lay  ---
The gcc.c-torture/execute/simd-[12].c tests PASS with -mno-lra but are FAILing
with -mlra.  Without your patch there are some ICEs, with your patch it's only
execution FAILs.

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #8 from Georg-Johann Lay  ---
Though it seems there are also new execution FAILs:

$ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim
--tool_opts=-mlra execute.exp=simd-[12].c -all"

Running
/home/john/xgnu/source/gcc-master/gcc/testsuite/gcc.c-torture/execute/execute.exp
...
PASS: gcc.c-torture/execute/simd-1.c   -O0  (test for excess errors)
PASS: gcc.c-torture/execute/simd-1.c   -O0  execution test
PASS: gcc.c-torture/execute/simd-1.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/execute/simd-1.c   -O1  execution test
PASS: gcc.c-torture/execute/simd-1.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/execute/simd-1.c   -O2  execution test
PASS: gcc.c-torture/execute/simd-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/simd-1.c   -O3 -g  execution test
PASS: gcc.c-torture/execute/simd-1.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/simd-1.c   -Os  execution test
PASS: gcc.c-torture/execute/simd-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.c-torture/execute/simd-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
PASS: gcc.c-torture/execute/simd-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
PASS: gcc.c-torture/execute/simd-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
PASS: gcc.c-torture/execute/simd-2.c   -O0  (test for excess errors)
PASS: gcc.c-torture/execute/simd-2.c   -O0  execution test
PASS: gcc.c-torture/execute/simd-2.c   -O1  (test for excess errors)
PASS: gcc.c-torture/execute/simd-2.c   -O1  execution test
PASS: gcc.c-torture/execute/simd-2.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/execute/simd-2.c   -O2  execution test
PASS: gcc.c-torture/execute/simd-2.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/simd-2.c   -O3 -g  execution test
PASS: gcc.c-torture/execute/simd-2.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/simd-2.c   -Os  execution test
FAIL: gcc.c-torture/execute/simd-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error: in patch_jump_insn, at
cfgrtl.cc:1303)
FAIL: gcc.c-torture/execute/simd-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.c-torture/execute/simd-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
PASS: gcc.c-torture/execute/simd-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
PASS: gcc.c-torture/execute/simd-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Attachment #59196|0   |1
is obsolete||

--- Comment #7 from Georg-Johann Lay  ---
Created attachment 59197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59197&action=edit
diff-test-v2.txt

Results are looking good on avr, too (I had a nit in PATH).

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #6 from Georg-Johann Lay  ---
...I am stuck here.  When I am testing locally, a single test like

$ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim
--tool_opts=-mlra compile.exp=2009-1.c -all"

works fine, but on the remote (cfarm421 in that case) I am getting
UNRESOLVED/UNSUPPORTED result.

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #5 from Georg-Johann Lay  ---
Created attachment 59196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59196&action=edit
diff-test.txt: avr testsuite delta

(In reply to denisc from comment #2)
> Johan can you test the patch ?
On x86_64, it bootstraps+regtests fine.

On avr, I am getting quite a delta like attached.

[Bug rtl-optimization/116781] [lra][avr] internal compiler error: in cselib_invalidate_regno, at cselib.cc:2545

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, ra
 Ever confirmed|0   |1
 Blocks||113934, 56183
 Target||avr
 CC||segher at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-09-19


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
[Bug 113934] Switch avr to LRA

[Bug rtl-optimization/116781] New: [lra][avr] internal compiler error: in cselib_invalidate_regno, at cselib.cc:2545

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

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

Bug ID: 116781
   Summary: [lra][avr] internal compiler error: in
cselib_invalidate_regno, at cselib.cc:2545
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59149
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59149&action=edit
pr45830.c: C test case

This ICE does not occur with the old reload (-mno-lra):

$ avr-gcc pr45830.c -S -mlra -O2 -funroll-loops
during RTL pass: postreload
pr45830.c: In function 'bar':
pr45830.c:79:1: internal compiler error: in cselib_invalidate_regno, at
cselib.cc:2545
   79 | }
  | ^
0x62b4a3 cselib_invalidate_regno
../../../source/gcc-master/gcc/cselib.cc:2545
0x62b8f7 cselib_invalidate_rtx(rtx_def*)
../../../source/gcc-master/gcc/cselib.cc:2699
0x62b938 cselib_invalidate_rtx_note_stores
../../../source/gcc-master/gcc/cselib.cc:2710
0x62c87c cselib_record_sets
../../../source/gcc-master/gcc/cselib.cc:3037
0x62d00d cselib_process_insn(rtx_insn*)
../../../source/gcc-master/gcc/cselib.cc:3194
0x7f083a10ed8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f083a10ee3f __libc_start_main_impl
../csu/libc-start.c:392

The respective lines in cselib.cc read:

cselib_invalidate_regno (unsigned int regno, machine_mode mode)
{
  unsigned int endregno;
  unsigned int i;

  /* If we see pseudos after reload, something is _wrong_.  */
  gcc_assert (!reload_completed || regno < FIRST_PSEUDO_REGISTER
  || reg_renumber[regno] < 0);

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240918 (experimental) (GCC)

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Blocks||113934, 56183
 Ever confirmed|0   |1
 Target||avr
   Keywords||ice-on-valid-code, ra
   Last reconfirmed||2024-09-19
 CC||segher at gcc dot gnu.org


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
[Bug 113934] Switch avr to LRA

[Bug rtl-optimization/116780] New: [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

Bug ID: 116780
   Summary: [lra][avr] internal compiler error: output_operand:
address operand requires constraint for X, Y, or Z
register
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59148
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59148&action=edit
pr64088.c: C test case

$ avr-gcc pr64088.c -S -O1 -mlra -fdump-rtl-final 
during RTL pass: final
dump file: pr64088.c.358r.final
pr64088.c: In function 'setup_tone_curves_center_boost':
pr64088.c:17:1: internal compiler error: output_operand: address operand
requires constraint for X, Y, or Z register
   17 | }
  | ^
0x6f39cc output_operand_lossage(char const*, ...)
../../../source/gcc-master/gcc/final.cc:3190
0xdf09d8 ptrreg_to_str
../../../source/gcc-master/gcc/config/avr/avr.cc:2416
0xdf0ba2 avr_print_operand_address
../../../source/gcc-master/gcc/config/avr/avr.cc:2484
0xdf17d6 avr_print_operand
../../../source/gcc-master/gcc/config/avr/avr.cc:2694
0x6f479f output_operand(rtx_def*, int)
../../../source/gcc-master/gcc/final.cc:3632
0x6f42c2 output_asm_insn(char const*, rtx_def**)
../../../source/gcc-master/gcc/final.cc:3525
0xdf0960 avr_asm_len
../../../source/gcc-master/gcc/config/avr/avr.cc:2392
0xdf7db0 out_movhi_mr_r
../../../source/gcc-master/gcc/config/avr/avr.cc:5756
0xdf46a0 output_movhi(rtx_insn*, rtx_def**, int*)
../../../source/gcc-master/gcc/config/avr/avr.cc:3981
0x6f0e7c get_insn_template(int, rtx_insn*)
../../../source/gcc-master/gcc/final.cc:2027
0x6f2a2f final_scan_insn_1
../../../source/gcc-master/gcc/final.cc:2773
0x6f2ea7 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../../source/gcc-master/gcc/final.cc:2886
0x6f0ca3 final_1
../../../source/gcc-master/gcc/final.cc:1977
0x6f59af rest_of_handle_final
../../../source/gcc-master/gcc/final.cc:4240
0x6f5d0e execute
../../../source/gcc-master/gcc/final.cc:4318
0x7f2d3446ed8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f2d3446ee3f __libc_start_main_impl
../csu/libc-start.c:392

The reason why avr.cc::ptrreg_to_str() runs into output_operand_lossage() is
that there are insns with invalid mem operands, like seen in the .final dump:

(insn 27 2 28 (parallel [
(set (mem:HI (plus:HI (reg/f:HI 32 __SP_L__)
(const_int 1 [0x1])) [1 b[0]+0 S2 A8])
(const_int 0 [0]))
(clobber (reg:CC 36 cc))
]) "pr64088.c":14:12 106 {*movhi}
 (expr_list:REG_UNUSED (reg:CC 36 cc)
(nil)))

The memory location is invalid because the stack pointer (regno __SP_L__)
cannot be used to access stack slots.  Indirect addressing and indirect
addressing with offset must use one of the X, Y or Z registers (regno HI:26,
HI:28, HI:30 respectively).

The code from old reload (-mno-lra) is correct: It loads SP to reg:HI 30 (Z):

(insn 28 2 29 (parallel [
(set (reg:HI 30 r30)
(reg/f:HI 32 __SP_L__))
(clobber (reg:CC 36 cc))
]) "pr64088.c":14:12 106 {*movhi}
 (expr_list:REG_UNUSED (reg:CC 36 cc)
(nil)))
(insn 29 28 30 (parallel [
(set (mem:HI (plus:HI (reg:HI 30 r30)
(const_int 1 [0x1])) [1 b[0]+0 S2 A8])
(const_int 0 [0]))
(clobber (reg:CC 36 cc))
]) "pr64088.c":14:12 106 {*movhi}
 (expr_list:REG_UNUSED (reg:CC 36 cc)
(nil)))

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240918 (experimental) (GCC)

[Bug tree-optimization/116779] [lra][avr] internal compiler error: in patch_jump_insn, at cfgrtl.cc:1303

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
 CC||segher at gcc dot gnu.org
   Keywords||ice-on-valid-code, ra
 Blocks||113934, 56183, 113932
   Last reconfirmed||2024-09-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
[Bug 113932] [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
[Bug 113934] Switch avr to LRA

[Bug tree-optimization/116779] New: [lra][avr] internal compiler error: in patch_jump_insn, at cfgrtl.cc:1303

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

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

Bug ID: 116779
   Summary: [lra][avr] internal compiler error: in
patch_jump_insn, at cfgrtl.cc:1303
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59146
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59146&action=edit
simd-2.c: C test case

This ICE does not occur without -mlra:

$ avr-gcc simd-2.c -S -mlra -O2

during RTL pass: reload
/home/john/xgnu/source/gcc-master/gcc/testsuite/gcc.c-torture/execute/simd-2.c:
In function 'main':
/home/john/xgnu/source/gcc-master/gcc/testsuite/gcc.c-torture/execute/simd-2.c:75:1:
internal compiler error: in patch_jump_insn, at cfgrtl.cc:1303
   75 | }
  | ^
0x5e8b48 patch_jump_insn
../../../source/gcc-master/gcc/cfgrtl.cc:1303
0x5e8bf8 redirect_branch_edge
../../../source/gcc-master/gcc/cfgrtl.cc:1330
0x5e9127 rtl_redirect_edge_and_branch
../../../source/gcc-master/gcc/cfgrtl.cc:1463
0x7fc402af1d8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7fc402af1e3f __libc_start_main_impl
../csu/libc-start.c:392

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240918 (experimental) (GCC)

[Bug rtl-optimization/116778] [lra][avr] Wrong code with -mlra (bitfld-lra.c)

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Last reconfirmed||2024-09-19
   Keywords||ra, wrong-code
 CC||segher at gcc dot gnu.org
 Blocks||113934, 56183
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
[Bug 113934] Switch avr to LRA

[Bug rtl-optimization/116778] [lra][avr] Wrong code with -mlra (bitfld-lra.c)

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

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

--- Comment #1 from Georg-Johann Lay  ---
...and without -mlra the code is correct, so likely caused by LRA.

[Bug rtl-optimization/116778] New: [lra][avr] Wrong code with -mlra (bitfld-lra.c)

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

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

Bug ID: 116778
   Summary: [lra][avr] Wrong code with -mlra (bitfld-lra.c)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59145
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59145&action=edit
bitfld-lra.c: C test case

$ avr-gcc -mmcu=atmega128 -dumpbase "" -save-temps -dp  -Os -mlra bitfld-lra.c
-o bitfld-lra.elf

produces wrong code for the attached test case

struct
{
  unsigned long long u33 : 33;
  unsigned long long u40 : 40;
  unsigned long long u41 : 41;
} a = { 0x10, 0, 0x10 }, b = { 1LL << 32, 0, 0 };
long long f = 1LL << 32, g = 1LL << 32;

int main (void)
{
  if (a.u33 * a.u33 != 0 || a.u33 * a.u40 * a.u33 != 0
  || a.u41 * a.u33 != 1LL << 40)
__builtin_abort();

  if (b.u33 + g != 1LL << 33 || b.u33 + f != 1LL << 33 || g + g != 1LL << 33)
__builtin_abort();
}

For the first addition "b.u33 + g != 1LL << 33" the asm reads something like

ldd r13,Y+1  ;  660 [c=4 l=1]  movqi_insn/3
mov r14,r13  ;  661 [c=4 l=1]  movqi_insn/0
lds r15,g+5  ;  662 [c=4 l=2]  movqi_insn/3
lds r16,g+6  ;  663 [c=4 l=2]  movqi_insn/3
lds r17,g+7  ;  664 [c=4 l=2]  movqi_insn/3
call __adddi3;  665 [c=32 l=2]  *adddi3_insn

where __adddi3 performs R10[8] + R18[8].  However, R13 has a wrong value of
0x01 due to the load insns 660 and 661 so that the value in R10[8] is
0x010100 instead of 0x01 when __adddi3 is called.

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240918 (experimental) (GCC)

[Bug rtl-optimization/116389] [15 regression] [avr] ICE in extract_constrain_insn for avrtiny and -O2 with ext-dce

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

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

--- Comment #8 from Georg-Johann Lay  ---
As it appears, this ICE only occurs with reload (-mno-lra) but not with LRA
(-mlra).  Provided PR116326 is fixed.

[Bug target/113934] Switch avr to LRA

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 116325, which changed state.

Bug 116325 Summary: [lra] ICE: in curr_insn_transform, at 
lra-constraints.cc:4283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116325

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug rtl-optimization/116325] [lra] ICE: in curr_insn_transform, at lra-constraints.cc:4283

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Georg-Johann Lay  ---
Dup of PR116326; at least the patch to resolve PR116326 also resolves the test
cases for this PR.

*** This bug has been marked as a duplicate of bug 116326 ***

[Bug target/113932] [meta-bug] Targets which should be ported to LRA

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
Bug 113932 depends on bug 116325, which changed state.

Bug 116325 Summary: [lra] ICE: in curr_insn_transform, at 
lra-constraints.cc:4283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116325

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug target/113934] Switch avr to LRA

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 116324, which changed state.

Bug 116324 Summary: [lra] error: inconsistent operand constraints in an 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116324

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 116325, which changed state.

Bug 116325 Summary: [lra] ICE: in curr_insn_transform, at 
lra-constraints.cc:4283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116325

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

--- Comment #15 from Georg-Johann Lay  ---
*** Bug 116325 has been marked as a duplicate of this bug. ***

[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 116324, which changed state.

Bug 116324 Summary: [lra] error: inconsistent operand constraints in an 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116324

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

--- Comment #14 from Georg-Johann Lay  ---
*** Bug 116324 has been marked as a duplicate of this bug. ***

[Bug target/113932] [meta-bug] Targets which should be ported to LRA

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
Bug 113932 depends on bug 116324, which changed state.

Bug 116324 Summary: [lra] error: inconsistent operand constraints in an 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116324

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug rtl-optimization/116324] [lra] error: inconsistent operand constraints in an 'asm'

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Georg-Johann Lay  ---
Dup of PR116326; at least the patch to relolve PR116326 also relolves the test
cases for this PR.

*** This bug has been marked as a duplicate of bug 116326 ***

[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 116326, which changed state.

Bug 116326 Summary: [lra] internal compiler error: in get_reload_reg, at 
lra-constraints.cc:755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Georg-Johann Lay  ---
Fixed.  Many thanks to Richard for his investigation.

[Bug target/113934] Switch avr to LRA

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 116326, which changed state.

Bug 116326 Summary: [lra] internal compiler error: in get_reload_reg, at 
lra-constraints.cc:755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug target/113932] [meta-bug] Targets which should be ported to LRA

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
Bug 113932 depends on bug 116326, which changed state.

Bug 116326 Summary: [lra] internal compiler error: in get_reload_reg, at 
lra-constraints.cc:755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

--- Comment #11 from Georg-Johann Lay  ---
Created attachment 59099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59099&action=edit
Proposed patch

https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662641.html

reload1.cc: rtl-optimization/116326 - Use RELOAD_ELIMINABLE_REGS.

The new macro is required because reload and LRA are using different
representations for a multi-register frame pointer.  As ELIMINABLE_REGS
is used to initialize static const objects, it can't depend on -mlra.

PR rtl-optimization/116326
gcc/
* reload1.cc (reg_eliminate_1): Initialize from
RELOAD_ELIMINABLE_REGS if defined.
* config/avr/avr.h (RELOAD_ELIMINABLE_REGS): Copy from ELIMINABLE_REGS.
(ELIMINABLE_REGS): Don't mention sub-regnos of the frame pointer.
* doc/tm.texi.in (Eliminating Frame Pointer and Arg Pointer)
: Add documentation.
* doc/tm.texi: Rebuild.
/testsuite/
* gcc.target/avr/torture/lra-pr116324.c: New test.
* gcc.target/avr/torture/lra-pr116325.c: New test.

[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

--- Comment #1 from Georg-Johann Lay  ---
(In reply to Georg-Johann Lay from comment #0)
> This ICE is relatively new; I don't see it with "gcc version 15.0.0
> 20240818".
So that's just a matter of options.  The PR also occurs with 20240818 for the
same test case:

$ avr-gcc -S lra-bug3.c -O3 -mmcu=avr4 -mlra

[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 116321, which changed state.

Bug 116321 Summary: [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, 
at config/avr/avr.cc:4572
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/116321] [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |15.0
 Status|NEW |RESOLVED

--- Comment #9 from Georg-Johann Lay  ---
Fixed by r15-3212.  The remaining ICE is a different PR116326.

[Bug target/113934] Switch avr to LRA

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 116321, which changed state.

Bug 116321 Summary: [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, 
at config/avr/avr.cc:4572
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug target/113932] [meta-bug] Targets which should be ported to LRA

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
Bug 113932 depends on bug 116321, which changed state.

Bug 116321 Summary: [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, 
at config/avr/avr.cc:4572
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=116550

--- Comment #10 from Georg-Johann Lay  ---
The test case passes now.  However, I see the relatively new PR116550 that
didn't occur with "gcc version 15.0.0 20240818".

[Bug rtl-optimization/116550] New: [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807

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

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

Bug ID: 116550
   Summary: [lra][avr] internal compiler error: in
final_scan_insn_1, at final.cc:2807
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59030
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59030&action=edit
lra-bug3.c: C test case from libgcc

$ avr-gcc lra-bug3.c -mmcu=avr25 -Os -S -mlra -fnon-call-exceptions

lra-bug3.c: In function '__divmoddi4':
lra-bug3.c:214:1: error: could not split insn
  214 | }
  | ^
(insn 528 1670 1671 (parallel [
(set (reg/v:SI 24 r24 [orig:146 __q1 ] [146])
(plus:SI (reg/v:SI 24 r24 [orig:146 __q1 ] [146])
(const_int -2 [0xfffe])))
(clobber (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 33 [0x21])) [6 %sfp+33 S1 A8]))
]) "lra-bug3.c":163:405 discrim 7 186 {addsi3}
 (nil))
during RTL pass: final
dump file: lra-bug3.c.357r.final
lra-bug3.c:214:1: internal compiler error: in final_scan_insn_1, at
final.cc:2807

That insn is invalid, of course.  With -da, the .ira dump reads:

(insn 500 499 501 65 (parallel [
(set (reg/v:SI 146 [ __q1 ])
(plus:SI (reg/v:SI 146 [ __q1 ])
(const_int -2 [0xfffe])))
(clobber (scratch:QI))
]) "lra-bug3.c":163:405 discrim 7 186 {addsi3}
 (nil))

so everything is fine (at least as far as the dump goes).  .reload has then:

(insn 1393 499 500 89 (set (reg/v:SI 18 r18 [orig:146 __q1 ] [146])
(mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 33 [0x21])) [6 %sfp+33 S4 A8])) "lra-bug3.c":163:405
discrim 7 119 {*movsi_split}
 (nil))
(insn 500 1393 1394 89 (parallel [
(set (reg/v:SI 18 r18 [orig:146 __q1 ] [146])
(plus:SI (reg/v:SI 18 r18 [orig:146 __q1 ] [146])
(const_int -2 [0xfffe])))
(clobber (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 33 [0x21])) [6 %sfp+33 S1 A8]))
]) "lra-bug3.c":163:405 discrim 7 186 {addsi3}
 (nil))

As it seems, R146 has been spilled to FP+33, and insn 1393 is loading it to
R18.  The clobber operand looks like a colateral damage.  FYI, the insn reads:

;; "addsi3"
;; "addsq3" "addusq3"
;; "addsa3" "addusa3"
(define_insn_and_split "add3"
  [(set (match_operand:ALL4 0 "register_operand"  "=??r,d ,r")
(plus:ALL4 (match_operand:ALL4 1 "register_operand" "%0,0 ,0")
   (match_operand:ALL4 2 "nonmemory_operand" "r,i ,n Ynn")))
   (clobber (match_scratch:QI 3 "=X,X ,&d"))]
  ""
  "#"
  "&& reload_completed"
  ...)

A QImode scratch is only required when op0 ends up in a non-d register (REGNO <
16), hence the 2nd alternatice should match and op3 = scratch:QI.

This ICE is relatively new; I don't see it with "gcc version 15.0.0 20240818".

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--with-long-double=64 --enable-languages=c,c++
gcc version 15.0.0 20240831 (experimental) (GCC)

[Bug tree-optimization/116548] New: [avr] ivopts Introducing expensive loop condition

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

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

Bug ID: 116548
   Summary: [avr] ivopts Introducing expensive loop condition
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

uint8_t add1 (const uint8_t *bb, uint8_t nn)
{
uint8_t sum = 0;
do
{
sum += *bb++;
} while (--nn);// Why not just 2 instructions: decrement + branch
return sum;
}

$ avr-gcc -mmcu=avr4 -S -Os -dp

has an expensive and overly complicated loop condition:

add1:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
mov r20,r24  ;  47  [c=4 l=1]  movqi_insn/0
mov r18,r24  ;  48  [c=4 l=1]  movqi_insn/0
mov r19,r25  ;  49  [c=4 l=1]  movqi_insn/0
ldi r24,0;  50  [c=4 l=1]  movqi_insn/0
.L5:
movw r30,r18 ;  38  [c=4 l=1]  *movhi/0
subi r18,-1  ;  39  [c=4 l=2]  *addhi3_clobber/1
sbci r19,-1
ld r25,Z ;  40  [c=4 l=1]  movqi_insn/3
add r24,r25  ;  41  [c=4 l=1]  *addqi3/0
mov r25,r22  ;  42  [c=4 l=1]  movqi_insn/0
sub r25,r18  ;  43  [c=4 l=1]  *subqi3/0
add r25,r20  ;  55  [c=4 l=1]  *op8.for.cczn.plus/1
brne .L5 ;  56  [c=4 l=1]  branch_ZN
/* epilogue start */
ret  ;  53  [c=0 l=1]  return

In the loop we have R18 and R30 (Z) holding the current address.

The loop condition is:
Insn 42 = Move nn to R25.
Insn 43 = Subtract (low byte of) current address from R25.
Insn 55 = Add (low byte of) initial addressto R25
Insn 56 = branch if result != 0

This are 4 instructions, and the register pressure is: A reg that holds nn, a
reg that holds the current address, a reg that holds the start address, and a
reg to compute the condition.

Instead, the code could just DECrement nn in R20 and branch on != 0 which has
less code, less cycles and less register pressure, even in the case when the
start address and nn are needed after the loop.

With -fno-ivopts, the code is:

add1:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
movw r18,r24 ;  51  [c=4 l=1]  *movhi/0
ldi r24,0;  44  [c=4 l=1]  movqi_insn/0
.L5:
movw r30,r18 ;  35  [c=4 l=1]  *movhi/0
ld r25,Z ;  36  [c=4 l=1]  movqi_insn/3
subi r18,-1  ;  37  [c=4 l=2]  *addhi3_clobber/1
sbci r19,-1
add r24,r25  ;  38  [c=4 l=1]  *addqi3/0
subi r22,lo8(1)  ;  49  [c=4 l=1]  *op8.for.cczn.plus/0
brne .L5 ;  50  [c=4 l=1]  branch_ZN
/* epilogue start */
ret  ;  47  [c=0 l=1]  return

Which uses nn in R22 with decrement (insn 49) and branch (insn 50).

Seems like ivopts cost model is off.

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--with-long-double=64 --enable-languages=c,c++
gcc version 15.0.0 20240829 (experimental) (GCC)

[Bug rtl-optimization/115523] [avr] Remove SFmode insns

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

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

--- Comment #6 from Georg-Johann Lay  ---
As it appears, the test case gives resonable code now; but only for trunk.

On v14, the code is still bloat.

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

--- Comment #9 from Georg-Johann Lay  ---
(In reply to Richard Sandiford from comment #8)
> (In reply to Georg-Johann Lay from comment #7)
> > What about the following line in reload1.h:
> > 
> > // Used during roload -> LRA transition because ELIMINABLE_REGS may depend
> > // on command line options.  Used in avr.h for example.
> > #define IN_RELOAD1_CC
> > 
> > and the use #ifdef IN_RELOAD1_CC in avr.h?
> > 
> > It's still a permanent change, but a no-op (except for avr.h) because the
> > macro is unused currently.
> Ah, yeah, and it keeps the change local to the code that is slated to
> disappear.  That sounds good to me FWIW.
I meant to place that macro in reload1.cc above all includes (not in reload1.h
which does not exist).

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

--- Comment #7 from Georg-Johann Lay  ---
(In reply to Richard Sandiford from comment #6)
> I don't think we should make any permanent changes to support this kind of
> manipulation, since it's only needed during the transition.
What about the following line in reload1.h:

// Used during roload -> LRA transition because ELIMINABLE_REGS may depend
// on command line options.  Used in avr.h for example.
#define IN_RELOAD1_CC

and the use #ifdef IN_RELOAD1_CC in avr.h?

It's still a permanent change, but a no-op (except for avr.h) because the macro
is unused currently.

There are places like varasm.cc and rtlanal.cc that use ELIMINABLE_REGS, but
they should follow the LRA convention.

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

--- Comment #5 from Georg-Johann Lay  ---
(In reply to Richard Sandiford from comment #4)
> (In reply to Georg-Johann Lay from comment #3)
> > It was due to problems with multi-reg frame-pointer. (AFAIR, using a
> > hard-frame-poiner besides frame-poiner didn't resolve the issues.)
> > 
> > My problem now is that avr.h has:
> > 
> > #define ELIMINABLE_REGS {   \
> > { ARG_POINTER_REGNUM, STACK_POINTER_REGNUM },   \
> > { ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM },   \
> > { FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM }, \
> > { FRAME_POINTER_REGNUM + 1, STACK_POINTER_REGNUM + 1 } }
> > 
> > but ira.cc uses that to initialize a static const array, hence there's no
> > way to depend that on options I guess?
> Yeah.  And I don't think it's worth adding a way to make it depend on an
> option, since it will only be a temporary state until LRA is fully
> supported.  Could you "just" remove the final entry locally while testing
> -mlra?
> 
> > One solution would be to skip upper parts of multi-part pointers in
> > elimination. (And maybe other places: TARGET_HARD_REGNO_SCRATCH_OK and
> > HARD_REGNO_RENAME_OK assume special handling for the high part of multi-reg
> > FP, too).
> In backend code, or in middle-end code?
avr_hard_regno_rename_ok and avr_hard_regno_scratch_ok require special handling
for the upper reg of FP.

> But either way, I think we should start with the assumption that the entry
> should be removed and make everything else work to that.  Unfortunately that
> probably excludes reload though, if the original problem that motivated the
> entry was there.

With the curret state of affairs, switching avr to LRA is not a good idea; you
can't even build neither libgcc nor libc.

Couldn't the elimination code in IRA / LRA just skip the high part? Or let
reload handle multi-reg FPs correctly, even though reload will come to an end?

Or maybe make eliminable regs an array that can be accessed in the backend, so
that avr.cc could adjust the entries in adjust_reg_alloc_order or
init_expanders to something like:

eliminables[3] = eliminables[2]

having a duplicate entry shouldn't hurt?

[Bug tree-optimization/116542] New: [avr] Missed post increment optimization

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

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

Bug ID: 116542
   Summary: [avr] Missed post increment optimization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59027&action=edit
incdec.c: GNU-C99 test case

The attached test case produces very expensive code.  For example the following
function (with decent resource consumption as comments):

$ avr-gcc incdec.c -mmcu=avr4 -S -Os -dp

uint8_t add1 (const uint8_t *bb, uint8_t nn)
{
// Set Z or X = bb (1 MOVW or 2 MOVs)
uint8_t sum = 0;   // 1 instruction
do
{
sum += *bb++;  // 2 instructions: POST_INC load + add
} while (--nn);// 2 instructions: decrement + branch
return sum;
}

add1:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
mov r20,r24  ;  47  [c=4 l=1]  movqi_insn/0
mov r18,r24  ;  48  [c=4 l=1]  movqi_insn/0
mov r19,r25  ;  49  [c=4 l=1]  movqi_insn/0
ldi r24,0;  50  [c=4 l=1]  movqi_insn/0
.L5:
movw r30,r18 ;  38  [c=4 l=1]  *movhi/0
subi r18,-1  ;  39  [c=4 l=2]  *addhi3_clobber/1
sbci r19,-1
ld r25,Z ;  40  [c=4 l=1]  movqi_insn/3
add r24,r25  ;  41  [c=4 l=1]  *addqi3/0
mov r25,r22  ;  42  [c=4 l=1]  movqi_insn/0
sub r25,r18  ;  43  [c=4 l=1]  *subqi3/0
add r25,r20  ;  55  [c=4 l=1]  *op8.for.cczn.plus/1
brne .L5 ;  56  [c=4 l=1]  branch_ZN
/* epilogue start */
ret  ;  53  [c=0 l=1]  return

The loop body uses R18 to hold and compute the address and R30 (Z) for
accessing, instead of just R30 with post-increment. (LD reg, Z+).

Then there is this fancy loop invariant of start_address - current_address + nn
== 0 instead of just decrementing nn (-fivopts issue / assumptions I guess).

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--with-long-double=64 --enable-languages=c,c++
gcc version 15.0.0 20240829 (experimental) (GCC)

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Richard Sandiford from comment #2)
> This is caused by the final entry in ELIMINABLE_REGS:
> 
>   { FRAME_POINTER_REGNUM + 1, STACK_POINTER_REGNUM + 1 }
> 
> I guess this was added to work around a reload bug involving multi-register
> pointers, but it shouldn't be necessary for LRA (and as this PR shows, it's
> actively harmful for LRA).
It was due to problems with multi-reg frame-pointer. (AFAIR, using a
hard-frame-poiner besides frame-poiner didn't resolve the issues.)

My problem now is that avr.h has:

#define ELIMINABLE_REGS {   \
{ ARG_POINTER_REGNUM, STACK_POINTER_REGNUM },   \
{ ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM },   \
{ FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM }, \
{ FRAME_POINTER_REGNUM + 1, STACK_POINTER_REGNUM + 1 } }

but ira.cc uses that to initialize a static const array, hence there's no way
to depend that on options I guess?

One solution would be to skip upper parts of multi-part pointers in
elimination. (And maybe other places: TARGET_HARD_REGNO_SCRATCH_OK and
HARD_REGNO_RENAME_OK assume special handling for the high part of multi-reg FP,
too).

[Bug rtl-optimization/116321] [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572

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

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

--- Comment #7 from Georg-Johann Lay  ---
(In reply to GCC Commits from comment #6)
> The PR is about an existing testcase that fails with LRA on m86k.
> 
> gcc/
> PR middle-end/116321
> * lra-constraints.cc (get_hard_regno): Only apply eliminations
> to existing hard registers.
> (get_reg_class): Likewise.
Hi Richard, as far as I can tell the bug is still somewhere in LRA.

With your patch and -Os like in the initial report, the test compiles fine. 
But with -O0, it still breaks:

$ avr-gcc -S lra-bug.c -O0 -mlra

lra-bug.c:6:1: internal compiler error: in get_reload_reg, at
lra-constraints.cc:755
6 | }
  | ^

gcc version 15.0.0 20240829 (experimental) (GCC)

...ok, the ICE is actually from a different place now (LRA instead of backend),
so the remaining ICE is PR116326 I guess?

[Bug target/115830] [avr] Make better use of SREG in conditional jumps

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/115830] [avr] Make better use of SREG in conditional jumps

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Georg-Johann Lay  ---
Added in v15.

For now, most cases are handled, except:

* Multi-byte bit operations that set SREG.N.

* Unary operations like NEG and COM.

[Bug tree-optimization/49857] [patch] Put constant switch-tables into flash

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|WONTFIX |---

[Bug target/116433] [AVR] cannot place template class static member variables in EEPROM

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

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

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Andrew Pinski from comment #1)
> The real fix is to have named address spaces support extended to C++. See
> PR43745.
That's a different issue.  EEPROM handling is too complicated, we don't want
/that/ code in the compiler and support > 300 devices where each one might need
different SFR handling.  When you want EEPROM support, you can just wrap
routines from AVR-LibC.  But that's not possible with PR43745 because there is
no way you can specify that VTABLEs be located in flash *and* to use the
appropriate access instructions.  It isn't possible in GCC either because just
putting VTALBEs in progmem won't fd the trick of using the right accessor
instructions.

[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints

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

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

--- Comment #26 from Georg-Johann Lay  ---
(In reply to Richard Biener from comment #25)
> I think there was a corresponding bug on the AVR side, not sure if that's
> now also resolved.
As far as I understand, the AVR issue is of a different kind

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321#c4

[Bug rtl-optimization/116325] [lra] ICE: in curr_insn_transform, at lra-constraints.cc:4283

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

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

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Georg-Johann Lay from comment #2)
> Created attachment 58958 [details]
> qsort.c. C test case
> 
> LRA can't compile qsort.c from libc; same ICE.

Just compile qsort.c with -mlra (optimizatio level and -mmcu don't seem to
matter).

[Bug rtl-optimization/116325] [lra] error: unable to generate reloads for:

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

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

--- Comment #2 from Georg-Johann Lay  ---
Created attachment 58958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58958&action=edit
qsort.c. C test case

LRA can't compile qsort.c from libc; same ICE.

[Bug rtl-optimization/116321] [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572

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

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

--- Comment #4 from Georg-Johann Lay  ---
(In reply to Richard Biener from comment #2)
> See the m68k bug - LRA/IRA _never_ use strict = 1
You mean PR116236? Its fix says:

> This matters on targets like m68k that support index extension
> and that require different classes for bases and indices.
I still see the ICE on avr with

gcc version 15.0.0 20240818 (experimental) (GCC)

but PR116236 has been fixes 2024-08-15.

[Bug rtl-optimization/116389] [15 regression] [avr] ICE in extract_constrain_insn for avrtiny and -O2 with ext-dce

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

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

--- Comment #7 from Georg-Johann Lay  ---
Created attachment 58955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58955&action=edit
Reduced C test case

$ avr-gcc pr116389-red.c -S -Os -mmcu=avrtiny

struct T { int val; };

void f_int (int);
char* get_pos (void);
struct T* get_pT (void);

void func (char i)
{
struct T t = * get_pT ();
unsigned diff = get_pos () - &i;

if (diff)
{
long val32 = t.val;
if (get_pos ())
val32 = diff;
if (get_pos ())
f_int (2 * val32);
}
}

[Bug target/116390] [15 regression] [avr] Another ICE for avrtiny and optimization

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #14 from Georg-Johann Lay  ---
(In reply to Detlef Vollmann from comment #13)
> The first bug got resolved with your patch (thanks again!) and
> the second one seems to be a duplicate of PR116389, which isn't
> fixed yet.

Closed again as fixed.  The PR with -O3 / "insn does not satisfy its
constraints internal compiler error: in extract_constrain_insn, at
recog.cc:2783" is a different issue that has already been reported as PR116389
(and which is still open to date).

[Bug target/115830] [avr] Make better use of SREG in conditional jumps

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

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 58953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58953&action=edit
proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659422.html

AVR: target/115830 - Make better use of SREG.N and SREG.Z.

This patch adds new CC modes CCN and CCZN for operations that
set SREG.N, resp. SREG.Z and SREG.N.  Add peephole2 patterns
to generate new compute + branch insns that make use
of the Z and N flags.  Most of these patterns need their own
asm output routines that don't do all the micro-optimizations
that the ordinary outputs may perform, as the latter have no
requirement to set CC in a usable way.

We don't use cmpelim because it cannot provide scratch regs
(which peephole2 can), and some of the patterns require a
scratch reg, whereas the same operations that don't set REG_CC
don't require a scratch.  See the comments in avr.md for details.

The existing add.for.cc* patterns are simplified as they no
more cover QImode, which is handled in a separate QImode case.
Apart from that, it adds 3 patterns for subtractions and one
pattern for shift left, all for multi-byte cases (HI, PSI, SI).

The add.for.cc* patterns now use CC[Z]Nmode, instead of the
formerly abuse of CCmode.

PR target/115830
gcc/
* config/avr/avr-modes.def (CCN, CCZN): New CC_MODEs.
* config/avr/avr-protos.h (avr_cond_branch): New from
ret_cond_branch.
(avr_out_plus_set_N, avr_op8_ZN_operator)
(avr_out_op8_set_ZN, avr_len_op8_set_ZN): New protos.
(ccn_reg_rtx, cczn_reg_rtx): New declarations.
* config/avr/avr.cc (avr_cond_branch): New from ret_cond_branch.
(avr_cond_string): Add bool cc_overflow_unusable argument.
(avr_print_operand) ['L']: Like 'j' but overflow unusable.
['K']: Like 'k' but overflow unusable.
(avr_out_plus_set_ZN): Remove handling of QImode.
(avr_out_plus_set_N, avr_op8_ZN_operator)
(avr_out_op8_set_ZN, avr_len_op8_set_ZN): New functions.
(avr_adjust_insn_length) [ADJUST_LEN_ADD_SET_N]: Hande case.
(avr_class_max_nregs): All MODE_CCs occupy one hard reg.
(avr_hard_regno_nregs): Same.
(avr_hard_regno_mode_ok) [REG_CC]: Allow all MODE_CC.
(pass_manager.h): Include it.
(ccn_reg_rtx, cczn_reg_rtx): New GTY variables.
(avr_init_expanders): Initialize them.
(avr_option_override): Run peephole2 a second time.
* config/avr/avr.md (adjust_len) [add_set_N]: New attr value.
(ALLCC, HI_SI): New mode iterators.
(CCname): New mode attribute.
(eqnegtle, cmp_signed, op8_ZN): New code iterators.
(branch): Handle CCNmode and CCZNmode.  Assimilate...
(difficult_branch): ...this insn.
(p1m1): Remove.
(gen_add_for__): Adjust to CCNmode and CCZNmode. Use
HISI as mode iterator.  Extend peephole2s that produce them.
(*add.for.eqne.): Extend to *add.for.cc[z]n..
(*ashift.for.ccn.): New insn and peephole2 to make them.
(*sub.for.cczn., "*sub-extend.for.cczn.:
New insns and peephole2s to make them.
(*op8.for.cczn.): New insn and peephole2 to make them.
* config/avr/predicates.md (const_1_to_3_operand)
(abs1_abs2_operand, signed_comparison_operator)
(op8_ZN_operator): New predicates.
gcc/testsuite/
* gcc.target/avr/pr115830-add.c: New test.
* gcc.target/avr/pr115830-add-c.c: New test.
* gcc.target/avr/pr115830-add-i.c: New test.
* gcc.target/avr/pr115830-and.c: New test.
* gcc.target/avr/pr115830-asl.c: New test.
* gcc.target/avr/pr115830-asr.c: New test.
* gcc.target/avr/pr115830-ior.c: New test.
* gcc.target/avr/pr115830-lsr.c: New test.
* gcc.target/avr/pr115830-asl32.c: New test.
* gcc.target/avr/pr115830-sub.c: New test.
* gcc.target/avr/pr115830-sub-ext: New test.

[Bug target/116390] [15 regression] [avr] Another ICE for avrtiny and optimization

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|REOPENED|WAITING

--- Comment #12 from Georg-Johann Lay  ---
(In reply to Detlef Vollmann from comment #10)
> Just in case you don't already know it, this is the commit that
> caused this regression:
>  h=88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2>
As Jeff wrote in comment #7, the paradoxical subregs present since that change
are as expected by that optimization.  The problem is that the register
allocator doesn't treat them correctly (PR116389).

The segmentation fault as reported above has been fixed with comment #2.  So
for what reason did you reopen this PR?

[Bug target/116390] [15 regression] [avr] Another ICE for avrtiny and optimization

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

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

--- Comment #11 from Georg-Johann Lay  ---
This PR is about a segmentation fault, which has been fixed already by the
commit above.

The "insn does not satisfy its constraints" ICE you are seeing now is PR116389.
 Please f'up to PR116389.

[Bug target/116407] [avr] error: relocation truncated to fit

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |14.3
 Resolution|--- |FIXED

--- Comment #6 from Georg-Johann Lay  ---
Fixed in v13.4 and v14.3+

[Bug target/116407] [avr] error: relocation truncated to fit

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Keywords||link-failure
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-18

[Bug target/116407] New: [avr] error: relocation truncated to fit

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

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

Bug ID: 116407
   Summary: [avr] error: relocation truncated to fit
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

This error can occur with some text peepholes:

void delay_62 (int x)
{
do
__builtin_avr_nops (62);
while (--x != -1);
}

int main (void)
{
return 0;
}

$ avr-gcc bug.c -O1 -save-temps -o bug.elf
bug.elf-bug.o: in function `.L2':
bug.c:(.text+0x84): relocation truncated to fit: R_AVR_7_PCREL against `.L2'
collect2: error: ld returned 1 exit status

[Bug rtl-optimization/116389] [avr][15 regression] ICE in extract_constrain_insn for avrtiny and -O2

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

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

--- Comment #5 from Georg-Johann Lay  ---
(In reply to Jeffrey A. Law from comment #4)
> "IRA doesn't understand the impact of paradoxical subreg" is a
> reasonable assessment.
RA should either assess the validity of a paradoxical subreg in the mode of a
subreg (SImode in this case), or just deal with the payload mode (HImode in
this case).

Paradoxicals behave differently on machines with small word size (like avr / 8
bits) than on a 32-bit machine:

On avr, HARD_REGNO_NREGS is larger for SImode (4 regs) than for HImode (2
regs).

Whereas on a 32-bit machine, QImode, HImode, SImode all just occupy one hard
reg.

Anyway, RA should just use the SUBREG_REG's mode, no?  What's the point of
letting ext-dce mark parts of a register as unused, when these parts are still
moved around and consume space on the stack and in the register file?

[Bug target/116390] [15 regression] [avr] Another ICE for avrtiny and optimization

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #8 from Georg-Johann Lay  ---
(In reply to Jeffrey A. Law from comment #7)
> It has always been advantageous if (when safe) patterns that accept
> zero/sign extension could also accept a paradoxical subreg.  With ext-dce it
> just make it even more useful to handle those cases.
I don't see how that would work, since extend has a different anatomy / rtx
type than a subreg (extend is "e" whilst subreg is "ep").  Hence this would
mean new patterns with subreg(s) instead of extend(s)?

> As far as the register allocator issue.  I wouldsuggest you look deeper
> into that since it could be either a register allocator bug or a bug in the
> backend.  I suggest first looking at the state after IRA to see if it is
> sensible.   If avr is still a reload target, note that we have a known bug
> with how reload handles paradoxical subregs that we're still working on.
The issue with the current PR was code like *(R28:HI + off) = R26:SI which can
be handled by avr.cc, but the asm out function was bogus and used %2 in
output_asm_insn() which was undefined, hence segmentation fault.

While code like *(R28:HI + off) = R26:SI is silly, it can still be suppoprted. 
This is different with PR116390 that has xxx = R30:SI which is invalid, because
R30 can hold one byte, R31 can hold one byte, and there are no more hard regs
after that.

As the transformations from ext-dce are supposed to be an optimization, the
sensible thing to do in the register allocator would be to only ever touch the
SUBREG_REG part of the subreg, i.e. only store (and allocate) HImode instead of
the extended mode.  (The patch for the current PR assumes that *(R28:HI + off)
= R26:SI originates from ext-dce and that the high 16 bits of R26:SI only
contain garbage, and hence don't require being written to the stack slot.  But
the right place would be RA only touching / allocating the required bytes).

> note that we have a known bug with how reload handles paradoxical
> subregs that we're still working on.
IIUC PR116389 is a DUP of some other PR?

[Bug rtl-optimization/116389] [avr][15 regression] ICE in extract_constrain_insn for avrtiny and -O2

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

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

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Jeffrey A. Law from comment #2)
> or a backend bug with avr.

I don't see what the avr backend is doing wrong.  I played around with
avr_hard_regno_mode_ok etc. and denied SImode for R30, but to no avail.

R30 is already assigned by IRA, and it appears that IRA doesn't understand the
impact of a paradoxical subreg; pseudo 78 should be treated as if it had
SImode, instead of the actual mode of that pseudo.

[Bug rtl-optimization/116402] [LRA] Improve hook documentation for reload -> LRA transition

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Blocks||113934, 113932
   Keywords||documentation, ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-17


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
[Bug 113932] [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
[Bug 113934] Switch avr to LRA

[Bug rtl-optimization/116402] New: [LRA] Improve hook documentation for reload -> LRA transition

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

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

Bug ID: 116402
   Summary: [LRA] Improve hook documentation for reload -> LRA
transition
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Trying to switch the avr backend to LRA, I came across a bunch of questions
which may pop up as other backend maintainers are trying to convert their
backends to LRA, too.

TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P explains the function of the hook from the
perspective of someone who is implementing a register allocator, but there is
no explanation whether it is a good idea (or even required) to implement it for
some specific target.  What form can "subst" take?  When the hook's purpose it
to avoid spills, then why not return always true? (Nobody wants spills when
they can be avoided).

TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: How would I describe addressing
capabilities for different named address-spaces?  Or will it only be used for
geeric address space? Stack slots? What kind of target code can I use to
investigate the effect of the hook? Or can it be inferred simply from the
device's register layout?

TARGET_SPILL_CLASS:  Can't we just return GENERAL_REGS as a spill class?

TARGET_COMPUTE_PRESSURE_CLASSES:  Again the documentation is from the
perspective of someone who is writing a register allocator, but not helpful for
someone who has to provide an implementation.

TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Similar issue.

TARGET_REGISTER_PRIORITY: When some registers are preferred over others and
hence we give them a higher priority, might that lead to more MOVs or spills? 
What's the relation to reg_alloc_order[] ?

What about reload_completed?  Does semantics stay the same? What about
reg_renumber[].  And reload_in_progress becomes lra_in_progress?

TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: The purpose / documentation of the hook
is clear for regalloc guys, but when and why and how would I do it for a
specific backend?  The hook has two "reg_class_t" parameters as inputs, and
none of the parameters does even have a name. "default hook always returns
given class" ... Which one? There are two indestinguishible ones.

What hooks / global variables are not used by LRA? LEGITIMIZE_RELOAD_ADDRESS is
one example, but presumably there are many more.

[Bug rtl-optimization/116325] [lra] error: unable to generate reloads for:

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

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 58945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58945&action=edit
C++ test case from libstdc++v3

This is a test case from libstdc++v3.  Compile with

$ avr-g++ pr116389.cpp -S -dumpbase "" -O2 -mmcu=avrtiny -dp
-fdump-rtl-ira-details -fdump-rtl-reload-details -mlra

error: unable to generate reloads for:
(call_insn/j 43 42 44 8 (parallel [
(set (reg:HI 24 r24)
(call (mem:HI (reg/f:HI 45 [ _8 ]) [0
*OBJ_TYPE_REF(_8;this_1(D)->7B) S2 A8])
(const_int 2 [0x2])))
(use (const_int 1 [0x1]))
])
"/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/include/bits/locale_facets.h":917:23
774 {call_value_insn}
 (expr_list:REG_DEAD (reg/f:HI 45 [ _8 ])
(expr_list:REG_DEAD (reg:QI 35 argH)
(expr_list:REG_DEAD (reg:HI 22 r22)
(expr_list:REG_DEAD (reg:HI 20 r20)
(expr_list:REG_UNUSED (reg:HI 24 r24)
(expr_list:REG_CALL_DECL (nil)
(nil)))
(expr_list:HI (use (reg:HI 24 r24))
(expr_list:HI (use (reg:HI 22 r22))
(expr_list:HI (use (reg:HI 20 r20))
(expr_list:HI (use (mem/f:HI (reg/f:HI 34 argL) [0  S2 A8]))
(nil))
during RTL pass: reload
dump file: pr116389.cpp.317r.reload
/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/include/bits/locale_facets.h:918:7:
internal compiler error: in curr_insn_transform, at lra-constraints.cc:4283

[Bug rtl-optimization/116390] [15 regression] [ext_dce] [avr] Another ICE for avrtiny and optimization

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

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

--- Comment #6 from Georg-Johann Lay  ---
(In reply to Detlef Vollmann from comment #5)
> Thanks for your patch.
> It solves the segfault ICE for -O2.
> But unfortunately  it doesn't solve the build for -O3 or -O4.
> It still produces the same error as before:
> 
> avr-gcc -O4 -mmcu=avrtiny-c -o pr116390.o pr116390.c
> pr116390.c: In function 'badFoo':
> pr116390.c:71:1: error: insn does not satisfy its constraints:
>71 | }
>   | ^
> (insn 29 148 3 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
> (const_int 9 [0x9])) [4 %sfp+9 S4 A8])
> (reg:SI 30 r30)) "pr116390.c":31:20 119 {*movsi_split}
>  (nil))
> during RTL pass: postreload
> pr116390.c:71:1: internal compiler error: in extract_constrain_insn, at
> recog.cc:2783


IMO that is PR116389 which is a regalloc issue or a problem with ext-dce,
whereas this one is about a (now fixed) typo in the avr backend.  Notice that
the error message changed.

> 0x1a169d0 internal_error(char const*, ...)
>   /ssd1/build/src/gcc/gcc/diagnostic-global-context.cc:491
> 0x63606b fancy_abort(char const*, int, char const*)
>   /ssd1/build/src/gcc/gcc/diagnostic.cc:1772
> 0x4e7641 _fatal_insn(char const*, rtx_def const*, char const*, int, char
> const*)
>   /ssd1/build/src/gcc/gcc/rtl-error.cc:108
> 0x4e7667 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>   /ssd1/build/src/gcc/gcc/rtl-error.cc:118
> 0x4e6199 extract_constrain_insn(rtx_insn*)
>   /ssd1/build/src/gcc/gcc/recog.cc:2783
> 0xc0d3d6 reload_cse_simplify_operands
>   /ssd1/build/src/gcc/gcc/postreload.cc:396
> 0xc0df65 reload_cse_simplify
>   /ssd1/build/src/gcc/gcc/postreload.cc:179
> 0xc0df65 reload_cse_regs_1
>   /ssd1/build/src/gcc/gcc/postreload.cc:227
> 0xc1009b reload_cse_regs
>   /ssd1/build/src/gcc/gcc/postreload.cc:65
> 0xc1009b execute
>   /ssd1/build/src/gcc/gcc/postreload.cc:2366

[Bug rtl-optimization/116389] [avr][15 regression] ICE in extract_constrain_insn for avrtiny and -O2

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||law at gcc dot gnu.org
   Last reconfirmed||2024-08-17
Summary|ICE in  |[avr][15 regression] ICE in
   |extract_constrain_insn for  |extract_constrain_insn for
   |avrtiny and -O2 |avrtiny and -O2
   Keywords||ra
 Blocks||56183
  Component|target  |rtl-optimization

--- Comment #1 from Georg-Johann Lay  ---
There is this insn from ext-dce (from -fdump-rtl-ira-details):

(insn 180 179 181 26 (set (reg/v:SI 70 [ __paddec ])
(subreg:SI (reg/v:HI 78 [ __len ]) 0))
"/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/include/bits/locale_facets_nonio.tcc":477:14
119 {*movsi_split}
 (nil))

Register allocation then assigns R30:HI to pseudo 78, but due to the
paradoxical subreg, this becomes R30:SI which is not a valid hard register
because R31 is the last valid general-purpose register.  The reload dump (from
-fdump-rtl-reload-details):

(insn 180 900 181 27 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 28 [0x1c])) [91 %sfp+28 S4 A8])
(reg:SI 30 r30))
"/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/inclu

This insn is not valid because R30:SI is not a valid hard reg, so it's no
wonder no valid insn constraint alternative is found and hence ICE.

So the question is whether that paradoxical subreg from ext-dce is valid in the
first place? Or is it a register allocation issue?

As an aside, -mlra also ICEs because the code is too complicated for LRA
(doesn't find reloads.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation

[Bug rtl-optimization/116390] [15 regression] [ext_dce] [avr] Another ICE for avrtiny and optimization

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Georg-Johann Lay  ---
Fixed in v14.3+

[Bug rtl-optimization/116390] [ext_dce][avr][15 regression]Another ICE for avrtiny and optimization

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Known to work||14.1.0
Summary|Another ICE for avrtiny and |[ext_dce][avr][15
   |optimization|regression]Another ICE for
   ||avrtiny and optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-17
  Component|target  |rtl-optimization
 Ever confirmed|0   |1
 CC||law at gcc dot gnu.org

--- Comment #1 from Georg-Johann Lay  ---
This seems to be a bug in ext_dce, and it can be worked around with
-fno-ext-dce.

>From .expand, there is this insn:

(insn 27 26 0 (set (reg/v:SI 60 [ n2 ])
(zero_extend:SI (reg/v:HI 63 [ n1 ]))) "pr116390-i.cpp":33:20 -1
 (nil))

which .ext_dce turns into a paradoxical subreg:

Processing insn:
   27: r60:SI=zero_extend(r63:HI)
  REG_DEAD r63:HI
Trying to simplify pattern:
(zero_extend:SI (reg/v:HI 63 [ n1 ]))
rescanning insn with uid = 27.
Successfully transformed to:
(subreg:SI (reg/v:HI 63 [ n1 ]) 0)

This paradoxical subreg it there until register allocation, which turns the
insn into

(insn 27 145 28 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 7 [0x7])) [4 %sfp+7 S4 A8])
(reg:SI 26 r26)) "pr116390-i.cpp":33:20 119 {*movsi_split}
 (nil))

and this is complete rubbish because R26:SI overlaps with the frame pointer
R28:HI.

Apart from that, representing a zero_extend as a paradoxical subreg is spoiling
all respective combine patterns that combine shifts with zero_extends.  Are we
supposed to rewrite all of them using paradoxical subregs?

[Bug target/85624] ICE when initializing array that is 128-byte aligned

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|15.0|14.3

--- Comment #7 from Georg-Johann Lay  ---
Fixed in v14.3+

[Bug target/85624] ICE when initializing array that is 128-byte aligned

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |15.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Georg-Johann Lay  ---
Fixed for v15.

[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints

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

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

--- Comment #10 from Georg-Johann Lay  ---
What do we do when strict=0 and legitimate_address_p passes a hard register
that is not valid?  Reject it?  Or is that fine and ra will fix it?

(There are cases where passes like insn combine are propagating hard regs into
operands where such registers won't fit, and which will eventually be kicked
out by ra.  Maybe avoiding such propagations gives better code?)

[Bug rtl-optimization/116321] [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572

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

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

--- Comment #1 from Georg-Johann Lay  ---
What I do not understand is when I also set -mlog=legitimate_address_p then I
only get logs that have strict=0 and not a single one with strict=1, like:

avr_addr_space_legitimate_address_p[fun64:split5(357)]: ret=true, mode=QI
strict=0 reload_completed=1 reload_in_progress=0 (reg_renumber):
(reg/f:HI 28 r28 [60])

This is for pass .split5 that runy way after reload, and strict=0 doesn't make
much sense to me.

[Bug other/116322] regenerate-opt-urls.py usage

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

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

--- Comment #2 from Georg-Johann Lay  ---
And it may be easier to use when we had a $builddir/gcc/regenerate-opt-urls.py
built by configure

1) $builddir/gcc/regenerate-opt-urls.py would know where $srcdir is.

2) $builddir/gcc/regenerate-opt-urls.py would know what HTML/$version to use
and could issue an error to run "make html" when it does not exist.

3) Shebang like #!/usr/bin/env python3 may not work on some build machines even
when they have Python3 installed.  configure can find a required Python version
or higher:

AM_PATH_PYTHON([], [AC_MSG_NOTICE([using $PYTHON to run
regenerate-opt-urls.py])])

AC_CONFIG_FILES([regenerate-opt-urls.py], [chmod +x regenerate-opt-urls.py])

Though GCC is using some older version of autotools, and I don't know how well
and reliable AM_PATH_PYTHON works there.

[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #7 from Georg-Johann Lay  ---
(In reply to Richard Biener from comment #2)
> Docs say
> 
> Legitimate addresses are defined in two variants: a strict variant and a
> non-strict one.  The @var{strict} parameter chooses which variant is
> desired by the caller.
> 
> The strict variant is used in the reload pass.  It must be defined so
> that any pseudo-register that has not been allocated a hard register is
> considered a memory reference.

I don't quite understand this sentence.

Does that mean that legitimate_address_p has to accept MEM as
(part of) a valid address, even when only a hard reg is
allowed as address?

Moreover legitimate_address_p seems outdated / incomplete and
TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P the right hook to use.

[Bug rtl-optimization/116326] [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-10
   Keywords||ice-on-valid-code, ra
 Blocks||56183, 113932, 113934
 Target||avr
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Georg-Johann Lay  ---
The opening should read:

$ avr-gcc addr-space-1-0-i.c -S -mlra
during RTL pass: reload
addr-space-1-0-i.c: In function 'main':
...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
[Bug 113932] [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
[Bug 113934] Switch avr to LRA

[Bug rtl-optimization/116326] New: [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755

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

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

Bug ID: 116326
   Summary: [lra] internal compiler error: in get_reload_reg, at
lra-constraints.cc:755
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58898&action=edit
GNU-C99 test case

$ avr-gcc addr-space-1-0-i.c -S -mlraduring RTL pass: reload
addr-space-1-0-i.c: In function 'main':
addr-space-1-0-i.c:85:1: internal compiler error: in get_reload_reg, at
lra-constraints.cc:755
   85 | }
  | ^

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--with-long-double=64 --enable-languages=c,c++

[Bug rtl-optimization/116325] [lra] error: unable to generate reloads for:

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target||avr
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code, ra
 Blocks||56183, 113932, 113934
   Last reconfirmed||2024-08-10


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
[Bug 113932] [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
[Bug 113934] Switch avr to LRA

[Bug rtl-optimization/116325] New: [lra] error: unable to generate reloads for:

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

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

Bug ID: 116325
   Summary: [lra] error: unable to generate reloads for:
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58897&action=edit
pr60040-2.c: GNU-C99 test case from gcc.target/avr

$ avr-gcc pr60040-2.c -mlra -S -Os

/pr60040-2.c:112:1: error: unable to generate reloads for:
  112 | }
  | ^
(call_insn 44 43 45 3 (parallel [
(set (reg:HI 24 r24)
(call (mem:HI (reg/f:HI 79 [ ops_25(D)->blank ]) [0 *_26 S2
A8])
(const_int 0 [0])))
(use (const_int 0 [0]))
]) "gcc.target/avr/pr60040-2.c":66:10 774 {call_value_insn}
 (expr_list:REG_DEAD (reg/f:HI 79 [ ops_25(D)->blank ])
(expr_list:REG_DEAD (reg:SI 20 r20)
(expr_list:REG_DEAD (reg:SI 16 r16)
(expr_list:REG_DEAD (reg:SI 12 r12)
(expr_list:REG_DEAD (reg:SI 8 r8)
(expr_list:REG_UNUSED (reg:HI 24 r24)
(expr_list:REG_CALL_DECL (nil)
(nil
(expr_list:HI (use (reg:HI 24 r24))
(expr_list:SI (use (reg:SI 20 r20))
(expr_list:SI (use (reg:SI 16 r16))
(expr_list:SI (use (reg:SI 12 r12))
(expr_list:SI (use (reg:SI 8 r8))
(nil)))
during RTL pass: reload
gcc.target/avr/pr60040-2.c:112:1: internal compiler error: in
curr_insn_transform, at lra-constraints.cc:4283

The insn in an indirect call, which should use the Z register (reg:HI 30) for
the target address.

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--with-long-double=64 --enable-languages=c,c++

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #11 from Georg-Johann Lay  ---
LRA even breaks building libgcc: PR116324

[Bug rtl-optimization/116324] [lra] error: inconsistent operand constraints in an 'asm'

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-08-10
 Blocks||113934, 113932, 56183
 Status|UNCONFIRMED |NEW
 Target||avr
   Keywords||ra, rejects-valid


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
[Bug 113932] [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
[Bug 113934] Switch avr to LRA

[Bug rtl-optimization/116324] New: [lra] error: inconsistent operand constraints in an 'asm'

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

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

Bug ID: 116324
   Summary: [lra] error: inconsistent operand constraints in an
'asm'
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58896&action=edit
lra-bug2.c: GNU-C99 test case

This error occurs when we try to build avr libgcc with -mlra:

$ avr-gcc lra-bug2.c -S -mlra -Os 

or

$ avr-gcc lra-bug2.c -S -mlra

In function '__f7_clr',
inlined from '__f7_madd_msub' at lra-bug2.c:77:3:
lra-bug2.c:42:3: error: inconsistent operand constraints in an 'asm'
   42 |   __asm ("%~call %x[f]"
  |   ^

The input constraint is like "z" (cc) where cc is a void* that perfectly fits
into 16-bit regster Z (reg:HI 30) which has register constraint "z".

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--with-long-double=64 --enable-languages=c,c++

[Bug other/116322] New: regenerate-opt-urls.py usage

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

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

Bug ID: 116322
   Summary: regenerate-opt-urls.py usage
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

$ ./regenerate-opt-urls.py  -h
usage: regenerate-opt-urls.py [-h] [--unit-test] base_html_dir src_gcc_dir

[...]

Usage (from build/gcc subdirectory):
  ../../src/gcc/regenerate-opt-urls.py HTML/gcc-14.0.0/ ../../src

Running the script terminates with an error:

$ ../../../source/gcc-master/gcc/regenerate-opt-urls.py HTML/gcc-15.0.0/
../../../source/gcc-master/
[...]
FileNotFoundError: [Errno 2] No such file or directory:
'HTML/gcc-15.0.0/gdc/Option-Index.html'

The problem is obviously that GCC hasn't been configured for D, which is clear
because the target does not support D.

The regenerate-opt-urls.py should document how to re-generate onyl specific
option files, namely the one that is associated to a changed .opt file
(somewhere in gcc/config/$target).

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #10 from Georg-Johann Lay  ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to Georg-Johann Lay from comment #4)
> > Would someone please explain what has to be done?
> > 
> > It's likely more than just
> > 
> > #define TARGET_LRA_P hook_bool_void_true
> 
> That is what you start with, though.  Or more likely, you have a -mlra
> flag to enable/disable it during development.  You can do that *right now*,
> and that enables other people to help you out with this, etc. :-)

Done: https://gcc.gnu.org/r15-2865

> Possibly some things will not work.

Ya, it's easier to break than I thought.  LRA already breaks for one of the
random programs I had lying around: PR116321

[Bug rtl-optimization/116321] [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-10
 Blocks||113934, 113932, 56183
 Target||avr
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
[Bug 113932] [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
[Bug 113934] Switch avr to LRA

[Bug rtl-optimization/116321] New: [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572

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

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

Bug ID: 116321
   Summary: [lra][avr] internal compiler error: in
avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

typedef __UINT64_TYPE__ uint64_t;

uint64_t fun64 (const __flash uint64_t *p)
{
  return *p;
}

runs into an ICE:

$ avr-gcc lra-bug.c -S -Os -da -mlra
during RTL pass: shorten
dump file: lra-bug.c.354r.shorten
lra-bug.c: In function 'fun64':
lra-bug.c:6:1: internal compiler error: in avr_out_lpm_no_lpmx, at
config/avr/avr.cc:4572
6 | }
  | ^

The respective line in avr.cc reads:

  gcc_assert (REG_Z == REGNO (addr));

because the only addressing modes for AS1 __flash are REG and POST_INC of REG_Z
(reg:HI 30).  However, the insn fed into the function as produced by LRA is
like found in lra-bug.c.317r.reload:

(insn 48 47 49 2 (set (reg:QI 25 r25 [+7 ])
(mem:QI (reg/f:HI 28 r28 [60]) [1 *p_2(D)+7 S1 A8 AS1]))
"lra-bug.c":6:1 86 {movqi_insn_split}
 (nil))

This insn clearly violates avr.cc's REGNO_MODE_CODE_OK_FOR_BASE_P which only
allows REG_Z (regno 30) as register for non-generic address-spaces like AS1.
And avr.cc'c MODE_CODE_BASE_REG_CLASS has:

  if (!ADDR_SPACE_GENERIC_P (as))
{
  return POINTER_Z_REGS;
}

but reg:HI 28 in insn 48 is not an element of POINTER_Z_REGS.


Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--with-long-double=64 --enable-languages=c,c++

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #8 from Georg-Johann Lay  ---
...more questions:

TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Same issue: This hook can change a
reload class.  The purpose is clear for regalloc guys, but when and d why and
how would I do it for a specific backend?  The hook has two "reg_class_t"
parameters as inputs, and no parameter does even have a name. "default hook
always returns given class" ... Which one? There are two indestinguishible
ones.

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #7 from Georg-Johann Lay  ---
...more questions:

What's the connexion between TARGET_REGISTER_PRIORITY and
ADJUST_REG_ALLOC_ORDER  / reg_alloc_order[].

What about reload_completed?  Does semantics stay the same? What about
reg_renumber[].  And reload_in_progress becomes lra_in_progress or what?

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #6 from Georg-Johann Lay  ---
...to be more specific:

TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P explains the function of the hook from the
perspective of someone who is implementing a register allocator, but there is
no explanation whether it is a good idea (or even required) to implement it for
some specific target.  What form can "subst" take?  When it's purpose it to
avoid spills, then why not always true? (Nobody wants stills when they can be
avoided).

TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: How would I describe addressing
capabilities for different named address-spaces?  What kind of target code can
I use to investigate the effect of the hook? Or can it inferred simply from the
device's register layout?

TARGET_SPILL_CLASS:  Can't we just return GENERAL_REGS as a spill class?

TARGET_COMPUTE_PRESSURE_CLASSES:  Requests that we should compute pressure
classes.  Now I know everything about it ...kidding.  Again it's from the
perspective of someone who is writing a register allocator, but of no use for
someone who has to provide an implementation.

TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Similar issue.

TARGET_REGISTER_PRIORITY: When some registers are preferred over others and
hence we give them a higher priority, might that lead to more MOVs or spills?

Finally: Who will fix fallout like ICEs (spill fails), performance issues, etc?
Just reporting them here as PR will likely not help much, because AVR is
ternary and hence any PR has priority P4 or less.  For example, Newlib dropped
AVR support because nobody did fix all the spill fail ICEs when building Newlib
for AVR.  lra just perform 2 rounds, and when it doesn't find an allocation it
just bails out with spill fail ICE.

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #4 from Georg-Johann Lay  ---
Would someone please explain what has to be done?

It's likely more than just

#define TARGET_LRA_P hook_bool_void_true

[Bug target/116295] [avr] unrecognizable insn when loading from address-space __flash

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|15.0|14.3
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Georg-Johann Lay  ---
Fixed in v14.3+

[Bug target/116295] New: [avr] unrecognizable insn when loading from address-space __flash

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

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

Bug ID: 116295
   Summary: [avr] unrecognizable insn when loading from
address-space __flash
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58877
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58877&action=edit
ice-flash.c: GNU-C99 test case

long val;

const __flash long* load4_flash (const __flash long *p)
{
val += *p++;
val += *p++;
return p;
}

triggers an ICE when compiled with

$ avr-gcc ice-flash.c -S -Os

It occurs in some situations when a value from __flash is loaded:

* The device has no LPMx instruction.
* More then 2 bytes are loaded.
* Pass mfuse-add finds an optimization opportunity.

The bug can be worked around with -mno-fuse-add.

ice-flash.c: In function 'load4_flash':
ice-flash.c:8:1: error: unrecognizable insn:
8 | }
  | ^
(insn 52 36 9 2 (parallel [
(set (reg:SI 22 r22)
(mem:SI (post_inc:HI (reg:HI 30 r30)) [1  S4 A8 AS1]))
(clobber (reg:CC 36 cc))
]) "ice-flash.c":5:9 -1
 (expr_list:REG_UNUSED (reg:CC 36 cc)
(expr_list:REG_INC (reg:HI 30 r30)
(nil
during RTL pass: cprop_hardreg
ice-flash.c:8:1: internal compiler error: in extract_insn, at recog.cc:2848

[Bug target/116295] [avr] unrecognizable insn when loading from address-space __flash

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||addr-space,
   ||ice-on-valid-code
   Assignee|unassigned at gcc dot gnu.org  |gjl at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-08-08
 Ever confirmed|0   |1
 Target||avr
   Target Milestone|--- |15.0

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Last reconfirmed|2012-01-07 00:00:00 |2024-8-2
 Status|RESOLVED|NEW
 Resolution|WONTFIX |---
Version|4.7.0   |15.0

[Bug target/97276] A whole if-block is ignored by avr-gcc 9.3.0

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED