https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94798
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |uros at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The xor -> mov 0 change happened in
r0-126146-g3b6d16993b9d6812f6212bce4f35547fd9e40457, it isn't about gcc not
knowing how to zero registers on x86, but about the ax = 0 insn being in
between the condition code setting insn and insn that uses that, where
obviously xor can't be used.
Later, when the insn scheduler reorders those, there is no pass that would have
LR problem computed and would try specifically for these.
E.g. peephole2 has APIs to check for that easily, but sched2 is after that, so
for peephole2 all we could try is to swap the CC setter insn with the reg = 0
insn without flags clobber.
That is just speaking about the xor.
