https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112526

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>:

https://gcc.gnu.org/g:f158bd511df1f55ebbbc0df3dee52c4400291984

commit r14-5519-gf158bd511df1f55ebbbc0df3dee52c4400291984
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Thu Nov 16 08:33:18 2023 +0100

    i386: Fix mov imm,%rax; mov %rdi,%rdx; mulx %rax -> mov imm,%rdx; mulx %rdi
peephole2 [PR112526]

    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  <ja...@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.

            * gcc.target/i386/bmi2-pr112526.c: New test.

Reply via email to