[Bug target/104637] [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637 --- Comment #4 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:ec1b9ba2d7913fe5e9deacc8e55e7539262f5124 commit r12-7415-gec1b9ba2d7913fe5e9deacc8e55e7539262f5124 Author: Vladimir N. Makarov Date: Mon Feb 28 16:43:50 2022 -0500 [PR104637] LRA: Split hard regs as many as possible on one subpass LRA hard reg split subpass is a small subpass used as the last resort for LRA when it can not assign a hard reg to a reload pseudo by other ways (e.g. by spilling non-reload pseudos). For simplicity the subpass works on one split base (as each split changes pseudo live range info). In this case it results in reaching maximal possible number of subpasses. The patch implements as many non-overlapping hard reg splits splits as possible on each subpass. gcc/ChangeLog: PR rtl-optimization/104637 * lra-assigns.cc (lra_split_hard_reg_for): Split hard regs as many as possible on one subpass. gcc/testsuite/ChangeLog: PR rtl-optimization/104637 * gcc.target/i386/pr104637.c: New.
[Bug target/104637] [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> If I change the testcase to following (so that it doesn't rely on
> __builtin_convertvector), it started ICEing with
> r0-122162-gb7aa4e9afcd3da4f09d6f982a663ea2094b1f2cf
> typedef short __attribute__((__vector_size__ (64))) U;
> typedef unsigned long long __attribute__((__vector_size__ (32))) V;
> typedef long double __attribute__((__vector_size__ (64))) F;
>
> int i;
> U u;
> F f;
>
> void
> foo (char a, char b, _Complex char c, V v)
> {
> u = (U) { u[0] / 0, u[1] / 0, u[2] / 0, u[3] / 0, u[4] / 0, u[5] / 0, u[6]
> / 0, u[7] / 0,
> u[8] / 0, u[0] / 0, u[9] / 0, u[10] / 0, u[11] / 0, u[12] / 0,
> u[13] /
> 0, u[14] / 0, u[15] / 0,
> u[16] / 0, u[17] / 0, u[18] / 0, u[19] / 0, u[20] / 0, u[21] / 0,
> u[22]
> / 0, u[23] / 0,
> u[24] / 0, u[25] / 0, u[26] / 0, u[27] / 0, u[28] / 0, u[29] / 0,
> u[30]
> / 0, u[31] / 0 };
> c += i;
> f = (F) { v[0], v[1], v[2], v[3] };
> i = (char) (__imag__ c + i);
> }
>
> In any case, I don't see anything wrong on the GIMPLE side and it isn't
> clear on reloading which insn it is ICEing.
It is a pitfall of LRA hard reg split subpass. It is a small subpass used as
the last resort for LRA when it can not assign a hard reg to a reload pseudo by
other ways (e.g. by spilling non-reload pseudos). For simplicity the subpass
works on one split base (as each split changes pseudo live range info). To
solve the problem the subpass should make as many splits as possible. This
requires to check overlapping hard reg splits.
In other words, the subpass should be considerably modified. I hope to commit
the patch on the next week.
[Bug target/104637] [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
--- Comment #2 from Jakub Jelinek ---
If I change the testcase to following (so that it doesn't rely on
__builtin_convertvector), it started ICEing with
r0-122162-gb7aa4e9afcd3da4f09d6f982a663ea2094b1f2cf
typedef short __attribute__((__vector_size__ (64))) U;
typedef unsigned long long __attribute__((__vector_size__ (32))) V;
typedef long double __attribute__((__vector_size__ (64))) F;
int i;
U u;
F f;
void
foo (char a, char b, _Complex char c, V v)
{
u = (U) { u[0] / 0, u[1] / 0, u[2] / 0, u[3] / 0, u[4] / 0, u[5] / 0, u[6] /
0, u[7] / 0,
u[8] / 0, u[0] / 0, u[9] / 0, u[10] / 0, u[11] / 0, u[12] / 0,
u[13] / 0, u[14] / 0, u[15] / 0,
u[16] / 0, u[17] / 0, u[18] / 0, u[19] / 0, u[20] / 0, u[21] / 0,
u[22] / 0, u[23] / 0,
u[24] / 0, u[25] / 0, u[26] / 0, u[27] / 0, u[28] / 0, u[29] / 0,
u[30] / 0, u[31] / 0 };
c += i;
f = (F) { v[0], v[1], v[2], v[3] };
i = (char) (__imag__ c + i);
}
In any case, I don't see anything wrong on the GIMPLE side and it isn't clear
on reloading which insn it is ICEing.
[Bug target/104637] [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.5 CC||vmakarov at gcc dot gnu.org Priority|P3 |P2 Summary|ICE: maximum number of LRA |[9/10/11/12 Regression] |assignment passes is|ICE: maximum number of LRA |achieved (30) with -Og |assignment passes is |-fno-forward-propagate |achieved (30) with -Og |-mavx since |-fno-forward-propagate |r9-5221-gd8fcab689435a29d |-mavx since ||r9-5221-gd8fcab689435a29d
