`switch` idiom recognition that fires on integers doesn't fire on pointers

[Kmeakin]

src1 gets optimized into tgt1, but src2 doesn't get optimized into tgt2:

uint64_t src1(uint64_t i) {
    switch (i) {
        case 0:
            return 0;
        case 1:
            return 1;
        case 2:
            return 2;
        default:
            __builtin_unreachable();
    }
}

uint64_t tgt1(uint64_t i) {
    if (i > 2) {
        __builtin_unreachable();
    }
    return i;
}

char* src2(uint32_t i, char* p) {
    switch (i) {
        case 0:
            return &p[0];
        case 1:
            return &p[1];
        case 2:
            return &p[2];
        default:
            __builtin_unreachable();
    }
}

char* tgt2(uint32_t i, char* p) {
    if (i > 2) {
        __builtin_unreachable();
    }
    return &p[i];
}

Motivation

Trying to optimize enum-to-string code by reducing number of globals that have to be loaded:

pub enum Foo {
    A,
    B,
    C,
}

pub fn src(foo: Foo) -> &'static str {
    match foo {
        Foo::A => "A",
        Foo::B => "B",
        Foo::C => "C",
    }
}

pub fn tgt(foo: Foo) -> &'static str {
    const ABC: &str = "ABC";

    match foo {
        Foo::A => &ABC[0..1],
        Foo::B => &ABC[1..2],
        Foo::C => &ABC[2..3],
    }
}

[Megan0704-1]

Hi! I’m interested in working on this issue. I’ve read the description and understand that the goal is to optimize switch statements with sequential cases into simpler if conditions when __builtin_unreachable() is present. This would be my first contribution to LLVM, and I’d love to investigate why src2 isn’t being optimized like src1. Could this issue be assigned to me? Thanks!

[nikic]

Without looking into this at all, I'd expect the problem is lack of "neutral element" support in sinking (&p[0] needs an explicit zero-offset GEP for sinking purposes).

[Megan0704-1]

I looked into this and noticed that src1 optimizes to tgt1 because LLVM easily simplifies integer returns, but src2 doesn’t optimize to tgt2, probably because LLVM is stricter with pointer arithmetic. I’m still learning about how LLVM optimizations work, but I think this might be a known limitation where it can’t prove that &p[i] is safe even when i is constrained.

If this optimization is critical, maybe someone more familiar with LLVM’s passes could investigate? For now, we could:

• Keep the explicit switch/match for pointers (even if it’s less concise), or
• Add a comment explaining why we can’t use &p[i] here

Please correct me if I’m misunderstanding how LLVM handles this!