https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563
--- Comment #6 from Yi <652023330028 at smail dot nju.edu.cn> ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Yi from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > _5 = var_0_16(D) + var_6_18(D);
> > > invariant up to level 1, cost 1.
> > >
> > > Basically because the cost is not high enough ...
> > >
> > > If you use --param=lim-expensive=1. then it will pull it out of the
> > > loop.
> > >
> > > So the cost model is doing the correct thing here ...
> >
> >
> > Thank you very much for your prompt reply! It took me some time to confirm
> > our work. For Example 1, GCC does exactly what you say it does. But for
> > Example 2, it doesn't seem to work as expected.
> >
> > We note that `(-(200 / var_10)) + (-var_8) + var_14 + var_2` as a whole can
> > be treated as a loop invariant, but gcc-trunk -O3 --param=lim-expensive=1
> > does not:
>
> _4 = _2 + var_24_lsm.5_21;
> _6 = _4 + _5;
>
> So this is again reassociation with LIM, the same issue as PR 111560.
Hi Andrew,
We would greatly appreicate if you can help us here.
extern int var_24;
void test(int var_2, int var_3, int var_8, int var_10, int var_14) {
for (int i_2 = -3247424; i_2 < 19; i_2 += var_3 + 1056714155)
{
if(var_3){
var_24 += (-(200 / var_10)) + (-var_8);
var_24 += var_14 + var_2;
}
i_2+=i_2/3;
}
}
Again, for the above code, if it were the reassociation issue that causes the
loop invariant not being moved out of the loop,
the following code should have the same problem. However, the code below is
being optimized properly, thereby, there
seems to be some other factors at play here. It would be great if you can
confirm it or (if possible) fix it. Thank you
so much!
extern int var_24;
int t;
void test(int var_2, int var_3, int var_8, int var_10, int var_14) {
for (int i_2 = -3247424; i_2 < 19; i_2 += var_3 + 1056714155)
{
var_24 += (-(200 / var_10)) + (-var_8);
var_24 += var_14 + var_2;
i_2+=i_2/3;
}
}
