------- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-27 15:47 -------
One thing is, that find_interesting_uses_address () produces bases that look
like &(&a[0])->s. I.e. they are not folded during IV base insertion via
if (!for_each_index (&base, idx_find_step, &ifs_ivopts_data)
|| zero_p (step))
goto fail;
Also we don't see that *&a[0] is an ARRAY_REF in idx_find_step, which may cause
other problems.
Another problem is that we record both
(const Foo*)&a[0]
and
&a[0]
as biv's which confuses IVOPTs a lot.
Stripping useless type conversions during biv discovery and folding after the
substitution above fixes the two problems. What remains is the use of an
out-of-bound array index and a (useless) offset:
<bb 2>:
ivtmp.39_2 = &x[1];
# ivtmp.39_4 = PHI <ivtmp.39_1(4), ivtmp.39_2(2)>;
<L0>:;
D.2068_10 = (int *) ivtmp.39_4;
MEM[base: D.2068_10, offset: -4B]{this->s} = 1;
ivtmp.39_1 = ivtmp.39_4 + 4B;
if (ivtmp.39_1 != &x[5]) goto <L5>; else goto <L2>;
here I do not see how IVOPTs decided that using &x[1] as base is better
than &x[0] (well, the cost for the former is 1 while for the latter is 2(!?)
I have a patch for the first two problems in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
