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
