------- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-27 16:02 ------- Subject: Re: -fivopts producing out of bounds array refs
> 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. I also have some patches for similar problems (in killloop-branch), unfortunately they mostly depend on http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00345.html that seems hopelessly stuck. > 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(!?) Welcome to the wonderful world of cost arithmetics :-) x86 backend pretends that more complicated memory addressing modes are cheaper, in order to persuade CSE to create them. Thus, given several equally costly ways how to express a memory reference, ivopts will choose the most complicated one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
