https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82580
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roger at nextmovesoftware dot
com
--- Comment #16 from Roger Sayle <roger at nextmovesoftware dot com> ---
Advance warning that the testcase pr82580.c will start FAILing due to
differences in register allocation following improvements to __int128 parameter
passing as explained in
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623756.html.
We might need additional reload alternatives/preferences to ensure that we
don't generate a movzbl. Hopefully, Jakub and/or Uros have some suggestions
for how best this can be fixed.
Previously, the SUBREGs and CLOBBERs generated by middle-end RTL expansion
(unintentionally) ensured that rdx and rax would never be used for __int128
arguments, which conveniently allowed the use of xor eax,eax; setc al in
peephole2 as AX_REG wasn't live. Now reload has more freedom, it elects to use
rax as at this point the backend hasn't expressed any preference that it would
like eax reserved for producing the result.
