The following testcase is miscompiled on x86_64 since PR110551 r14-4968
commit. That commit added 2 peephole2s, one for
mov imm,%rXX; mov %rYY,%rax; mulq %rXX -> mov imm,%rax; mulq %rYY
which I believe is ok, and another one for
mov imm,%rXX; mov %rYY,%rdx; mulx %rXX, %rZZ, %rWW -> mov imm,%rdx; mulx %rYY, %rZZ, %rWW
which is wrong. Both peephole2s verify that %rXX above is dead at
the end of the pattern, by checking if %rXX is either one of the
registers overwritten in the multiplication (%rdx:%rax in the first
case, the 2 destination registers of mulx in the latter case), because
we no longer set %rXX to that immediate (we set %rax resp. %rdx to it
instead) when the peephole2 replaces it. But, we also need to ensure
that the other register previously set to the value of %rYY and newly
to imm isn't used after the multiplication, and neither of the peephole2s
does that. Now, for the first one (at least assuming in the % pattern
the matching operand (i.e. hardcoded %rax resp. %rdx) after RA will always go
first) I think it is always the case, because operands[2] if it must be %rax
register will be overwritten by mulq writing to %rdx:%rax. But in the
second case, there is no reason why %rdx couldn't be used after the pattern,
and if it is (like in the testcase), we can't make those changes.
So, the patch checks similarly to operands[0] that operands[2] (which ought
to be %rdx if RA puts the % match_dup operand first and nothing swaps it
afterwards) is either the same register as one of the destination registers
of mulx or dies at the end of the multiplication.
2023-11-16 Jakub Jelinek <jakub@redhat.com>
PR target/112526
* config/i386/i386.md
(mov imm,%rax; mov %rdi,%rdx; mulx %rax -> mov imm,%rdx; mulx %rdi):
Verify in define_peephole2 that operands[2] dies or is overwritten
at the end of multiplication.