------- Comment #10 from rguenther at suse dot de 2006-04-27 16:09 ------- Subject: Re: -fivopts producing out of bounds array refs
On Thu, 27 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote: > > 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. I thought there was consensus and approval on the generic parts. Maybe it's time to ping these again, as they were clearly submitted before stage3. > > 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. *sigh* :/ Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
