https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91320
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
CC| |law at redhat dot com,
| |vmakarov at redhat dot com
--- Comment #3 from Jeffrey A. Law <law at redhat dot com> ---
So here's the pushing to the coloring and assignment from IRA:
Pushing a1(r103,l0)(cost 0)
Pushing a9(r106,l0)(cost 0)
Pushing a3(r95,l0)(cost 0)
Pushing a10(r105,l0)(cost 0)
Pushing a2(r93,l0)(cost 0)
Pushing a5(r82,l0)(cost 0)
Pushing a7(r96,l0)(cost 0)
Pushing a6(r98,l0)(cost 0)
Pushing a17(r100,l0)(cost 0)
Pushing a0(r92,l0)(cost 0)
Pushing a4(r91,l0)(cost 0)
Popping a4(r91,l0) -- assign reg 0
Popping a0(r92,l0) -- assign reg 36
Popping a17(r100,l0) -- assign reg 1
Popping a6(r98,l0) -- assign reg 2
Popping a7(r96,l0) -- assign reg 2
Popping a5(r82,l0) -- assign reg 37
Popping a2(r93,l0) -- assign reg 5
Popping a10(r105,l0) -- assign reg 5
Popping a3(r95,l0) -- assign reg 4
Popping a9(r106,l0) -- assign reg 4
Popping a1(r103,l0) -- assign reg 0
Note how allocno 4 gets pushed after allocno 4. That's because allocno 4 has a
higher frequency. As a result allocno 4 gets popped before allocno 0. Allocno
4 gets the first crack at getting assigned %eax (and allocno 4 really doesn't
care what register it gets as long as it's GENERAL_REGS).
And since a4 and a0 conflict, a0 can't get %eax which results in the extra move
instruction.
Which isn't really a surprise as a4 is used more within the loop and is thus a
higher priority to allocate.
One might consider raising the priority of allocnos which are more sensitive to
what register they're allocated to. But that's a risky proposition and would
have to be extensively benchmarked to determine its impact, assuming we could
even come up proposed heuristics in this space.
Anyway, I'm cc-ing Vlad as our register allocation expert so that he can take a
looksie. I'll also attach a usable testcase.
