https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109184
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> Confirmed with -O2 -floop-interchange. There's just a single interchange
> done:
>
> runData/keep/in.713.c:648:32: optimized: loops interchanged in loop nest
>
> that's in func_2 for the nest
>
> for (g_149 = 0; (g_149 > (-15)); g_149--)
> {
> for (l_1719 = 4; (l_1719 >= 1); l_1719 -= 1)
> {
> for (l_1721 = 0; (l_1721 >= 0); l_1721 -= 1)
> {
> struct S1 l_1935 = {0x13186D76L,0xC9L,36,24,1L,0x87L};
> for (g_1179 = 0; (g_1179 <= 4); g_1179 += 1)
> {
> int32_t l_1942 = (-3L);
> int32_t *****l_1947 = &l_1946[0][6];
> int i, j;
> l_1942 ^= ((safe_add_func_uint64_t_u_u((l_1935 ,
> (((l_1936[1] != (void*)0) < (*g_511)) & (g_1731[(l_1719 + 1)][l_1721] &=
> (((0x943C8AB0L | 0xE398A931L) != g_20) , (0x26L &
> (safe_add_func_uint64_t_u_u((--l_1930[g_1179]), 0xFC07342370A5FE25LL))))))),
> 4L)) <= p_5.f0);
> l_1943[0][1][1]++;
> l_1949 = (((*l_1947) = l_1946[0][6]) == g_1948);
> }
> }
> }
> }
And we are interchanging the outer two loops. Since the outer loop IV isn't
used in the body it doesn't change anything data dep wise?
Interchanging the loops in the source reproduces the issue, so somehow
for the only use of l_1719
(g_1731[(l_1719 + 1)][l_1721] &= (((0x943C8AB0L | 0xE398A931L) != g_20) ,
(0x26L & (safe_add_func_uint64_t_u_u((--l_1930[g_1179]),
0xFC07342370A5FE25LL)))))
it makes a difference. It's
g_1731[(l_1719 + 1)][l_1721] &= val;
the order we & values into it shouldn't matter. But it's so much obfuscated
code ...
