[GlobalIsel] Use aext in ctlz_zero_undef widenScalar expansion

[AlexMaclean]

Use G_ANYEXT instead of G_ZEXT when widening the source of G_CTLZ_ZERO_UNDEF. The extended upper bits are immediately shifted out by the subsequent left-shift, so zero-extending is unnecessarily constraining.

Before:

    %wide = G_ZEXT %src
    %shifted = G_SHL %wide, sizeDiff
    %result = G_CTLZ_ZERO_UNDEF %shifted

After:

    %wide = G_ANYEXT %src
    %shifted = G_SHL %wide, sizeDiff
    %result = G_CTLZ_ZERO_UNDEF %shifted

[llvmbot]

@llvm/pr-subscribers-backend-arm
@llvm/pr-subscribers-backend-amdgpu

@llvm/pr-subscribers-llvm-globalisel

Author: Alex MacLean (AlexMaclean)

Changes

---

Full diff: https://github.com/llvm/llvm-project/pull/181506.diff

1 Files Affected:

• (modified) llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp (+1)

diff --git a/llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp b/llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
index 41b79ccb4e4d1..ffd0814f86010 100644
--- a/llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
@@ -2816,6 +2816,7 @@ LegalizerHelper::widenScalar(MachineInstr &MI, unsigned TypeIdx, LLT WideTy) {
     switch (Opcode) {
     case TargetOpcode::G_CTTZ:
     case TargetOpcode::G_CTTZ_ZERO_UNDEF:
+    case TargetOpcode::G_CTLZ_ZERO_UNDEF: // undef bits shifted out below
       ExtOpc = TargetOpcode::G_ANYEXT;
       break;
     case TargetOpcode::G_CTLS:

[github-actions]

🐧 Linux x64 Test Results

• 190078 tests passed
• 5073 tests skipped

✅ The build succeeded and all tests passed.

[github-actions]

🪟 Windows x64 Test Results

• 130882 tests passed
• 2938 tests skipped

✅ The build succeeded and all tests passed.

[topperc]

LGTM

[e-kud]

Interesting. LGTM!

[arsenm]

I'd expect this to be caught by other optimizations, but I think GlobalISel is still missing SimplifyDemandedBits

[AlexMaclean]

I'd expect this to be caught by other optimizations, but I think GlobalISel is still missing SimplifyDemandedBits

Yea, I think this is missing. Even if it were supported, since the GIsel combiner is more opt-in I think it can't hurt to generate the best sequence of instructions for this lowering directly, instead of relying on optimization. Any concerns with this change as is?