https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (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.
