[all-commits] [llvm/llvm-project] bcae30: GlobalISel: Use G_UADDE when narrowing G_UMULH

[Matt Arsenault via All-commits]

  Branch: refs/heads/users/arsenm/global-isel-use-uadde-narrow-umulh
  Home:   https://github.com/llvm/llvm-project
  Commit: bcae30eeab621828a858eced2c8b6e81802011d7
      https://github.com/llvm/llvm-project/commit/bcae30eeab621828a858eced2c8b6e81802011d7
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2024-06-30 (Sun, 30 Jun 2024)

  Changed paths:
    M llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-mul.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-sdiv.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-srem.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-udiv.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-umulh.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-umulo.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-urem.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/sdiv.i64.ll
    M llvm/test/CodeGen/AMDGPU/GlobalISel/sdivrem.ll
    M llvm/test/CodeGen/AMDGPU/GlobalISel/srem.i64.ll
    M llvm/test/CodeGen/AMDGPU/GlobalISel/udiv.i64.ll
    M llvm/test/CodeGen/AMDGPU/GlobalISel/udivrem.ll
    M llvm/test/CodeGen/AMDGPU/GlobalISel/urem.i64.ll
    M llvm/test/CodeGen/Mips/GlobalISel/legalizer/mul.mir
    M llvm/test/CodeGen/Mips/GlobalISel/llvm-ir/mul.ll
    M llvm/test/CodeGen/RISCV/GlobalISel/legalizer/legalize-mul-ext-rv32.mir
    M llvm/test/CodeGen/RISCV/GlobalISel/legalizer/legalize-mul-ext-rv64.mir

  Log Message:
  -----------
  GlobalISel: Use G_UADDE when narrowing G_UMULH

This greatly shrinks the AMDGPU div64 expansion.

Instead of adding a zext of the condition output, add a zero and use
the carry in to G_UADDE. This is closer to how the DAG expansion using
umulh does it, and it seems more natural to leave the boolean output
as a boolean input. We should have a combine to form G_UADDE from this
pattern, but the legalizer shouldn't create extra work for the
combiner if it can help it.

The Mips cases are regressions, but the DAG lowering for muli128 seems
to not use the expansion involving MULHU/MULHS at all. The DAG output
is radically different than GlobalISel as-is, so it seems like Mips
should be using a different legalization strategy here to begin with.

The RISCV legalizer tests look worse for the mul i96 case, but those
didn't exist when I wrote this patch and forgot about it 4 years ago,
so I haven't really looked into why. We've entered the age where most tests
should just be using IR, so I don't  know if this matters or not (the IR mul
test doesn't seem to cover i96)



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications