http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563
--- Comment #3 from Jiangning Liu <jiangning.liu at arm dot com> 2012-03-13
08:11:40 UTC ---
First, I tried gcc 4.4.3 on x86-64, and it works for this test case, so it is
to some extension a GCC regression.
Second, I tried trunk, and I can reproduce the failure for this test case. It
means there are still some other bugs hidden after my scalar evolution
improvement on address of array element.
Third, loop ivopt should be able to find &a is the base object of a selected IV
candidate after the analysis from simple_iv. After loop ivopt, I see the
following dump,
Selected IV set:
candidate 5 (important)
depends on 1
var_before i_13
var_after i_6
original biv
type int
base k_2(D)
step k_2(D)
candidate 6
depends on 1
var_before ivtmp.11_9
var_after ivtmp.11_1
incremented before exit test
type unsigned long
base (unsigned long) ((int *) &a + (sizetype) k_2(D) * 4)
step (unsigned long) ((sizetype) k_2(D) * 4)
base object (void *) &a
So &a is already identified as an IV base object, but somehow only one &a is
hoisted out of loop, while the other one isn't.
<bb 4>:
D.1728_15 = (sizetype) k_2(D);
D.1729_16 = D.1728_15 * 4;
D.1730_17 = (sizetype) k_2(D);
D.1731_18 = D.1730_17 * 4;
D.1732_19 = &a + D.1731_18;
ivtmp.11_20 = (unsigned long) D.1732_19;
<bb 5>:
# i_13 = PHI <i_6(7), k_2(D)(4)>
# ivtmp.11_9 = PHI <ivtmp.11_1(7), ivtmp.11_20(4)>
a_p.0_4 = (int *) ivtmp.11_9;
MEM[(int *)&a][i_13] = 100;
i_6 = i_13 + k_2(D);
ivtmp.11_1 = ivtmp.11_9 + D.1729_16;
if (i_6 <= 999)
goto <bb 7>;
else
goto <bb 6>;
This statement,
MEM[(int *)&a][i_13] = 100;
is expected to be like,
D.4086_21 = (void *) ivtmp.11_9;
MEM[base: D.4086_21, offset: 0B] = 100;
after loop ivopt.
