shl nuw + zext adds unnecessary masking

[purplesyringa]

Godbolt

#include <stdint.h>

uint32_t f(uint16_t x) {
    if (x >= 8192) {
        __builtin_unreachable();
    }
    return (uint16_t)(x << 3);
}

uint32_t g(uint16_t x) {
    if (x >= 8192) {
        __builtin_unreachable();
    }
    return (uint16_t)(x << 3) | ((uint32_t)x << 16);
}

Expected behavior: x fits in 13 bits, so x << 3 fits in 16 bits and the cast can be optimized out. Current lowering:

f(unsigned short):
        shl     edi, 3
        movzx   eax, di ; unnecessary
        ret

g(unsigned short):
        mov     eax, edi
        and     eax, 8191 ; unnecessary
        shl     edi, 16
        lea     eax, [rdi + 8*rax]
        ret

IR recognizes shift as non-wrapping with shl nuw, so this is just a missed opt in isel.

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: Alisa Sireneva (purplesyringa)

[Godbolt](https://godbolt.org/z/jGcYTYv3d)

#include <stdint.h>

uint32_t f(uint16_t x) {
    if (x >= 8192) {
        __builtin_unreachable();
    }
    return (uint16_t)(x << 3);
}

uint32_t g(uint16_t x) {
    if (x >= 8192) {
        __builtin_unreachable();
    }
    return (uint16_t)(x << 3) | ((uint32_t)x << 16);
}

Expected behavior: x fits in 13 bits, so x << 3 fits in 16 bits and the cast can be optimized out. Current lowering:

f(unsigned short):
        shl     edi, 3
        movzx   eax, di ; unnecessary
        ret

g(unsigned short):
        mov     eax, edi
        and     eax, 8191 ; unnecessary
        shl     edi, 16
        lea     eax, [rdi + 8*rax]
        ret

IR recognizes shift as non-wrapping with shl nuw, so this is just a missed opt in isel.

[Explorer09]

The second example (g) doesn't make sense. Why are you intentionally downcasting the integer from the default int type to uint16_t?

[purplesyringa]

This is minimized from Rust, where integer promotion isn't a thing. Less generously, casting to the target type before the shift instead of after produces worse codegen on larger types, supposedly due to instcombine firing and replacing the logic with multiplication, which then lowers suboptimally. Sorry for not bringing this up earlier, that's an obvious omission in retrospect.

[RKSimon]

define dso_local range(i32 0, 65529) i32 @f(i16 noundef zeroext %x) local_unnamed_addr {
entry:
  %cmp = icmp ult i16 %x, 8192
  tail call void @llvm.assume(i1 %cmp)
  %0 = shl nuw i16 %x, 3
  %conv3 = zext i16 %0 to i32
  ret i32 %conv3
}

->

Initial selection DAG: %bb.0 'f:entry'
SelectionDAG has 14 nodes:
  t0: ch,glue = EntryToken
  t6: i16 = Constant<3>
            t2: i32,ch = CopyFromReg t0, Register:i32 %0
          t4: i32 = AssertZext t2, ValueType:ch:i16
        t5: i16 = truncate t4
      t8: i16 = shl nuw t5, Constant:i8<3>
    t9: i32 = zero_extend t8
  t12: ch,glue = CopyToReg t0, Register:i32 $eax, t9
  t13: ch = X86ISD::RET_GLUE t12, TargetConstant:i32<0>, Register:i32 $eax, t12:1

It comes down to whether we can use the assume to tweak that AssertZext to:

t4: i32 = AssertZext t2, ValueType:ch:i13

[actinks]

It comes down to whether we can use the assume to tweak that AssertZext to:

t4: i32 = AssertZext t2, ValueType:ch:i13

@RKSimon
The 'assume' instruction has already been removed at this point—see:
https://github.com/llvm/llvm-project/blob/8a4cc440f200154d6514df6db55789991aae5a4f/llvm/lib/CodeGen/CodeGenPrepare.cpp#L626C3-L626C45

[RKSimon]

precisely - its whether CGP can extract anything from them before it strips them

[purplesyringa]

Why are you focusing on assume in particular? Previous passes infer nuw in shl based on the assumption, which seems easier to track.