https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563
--- Comment #4 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. I see. Thank you very much for your reply!
