https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116
Pat Haugen <pthaugen at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |77536 --- Comment #8 from Pat Haugen <pthaugen at gcc dot gnu.org> --- Marking this as depends on pr77536. Before vectorization the loops have a BB freq of 8500, after vectorization the vectorized version of the loops have freq=536. It then appears IRA/reload pick the loop block as a spill location because the frequency is less than the surrounding preheader/exit blocks. To test this theory I compiled the 2 testcases under gdb and modified the frequency of the loop block at the start of ira() to be slightly greater than the preheader and the loads no longer occurred in the loop. For the first testcase, the loop is colder than the surrounding code even with r241172, but my change in r241173 made some changes in the CFG by removing a peeled copy of the loop. So there's a difference in CFGs which leads to differences in BB frequencies that I suspect is not passing some threshhold in the latter case and resulting in spill in the loop. For the second testcase, my patch in r241170 resulted in no changes to the CFG, only changes to the BB frequencies. After unrolling, the loop in r241169 ends up having a frequency greater than the surrounding code due to the incorrect code that was in loop-unroll.c. r241170 corrected that code and maintained the initial representation that the loop is colder than the surrounding code, which again leads to spill in the loop. Even though spill is not the desired result, I maintain that the changes in r241170 are the correct thing to do. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77536 [Bug 77536] Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data