[X86] 64-bit constant compiled to `movabs`+`add` after branch

[dzaima]

https://c.godbolt.org/z/GEb9G3bMq

This C code, compiled with -O3:

#include <inttypes.h>
#include <stdlib.h>
uint64_t foo(uint64_t x) {
    if (x >> 47 == 0xffe5) { // equivalent to (x & 0xffff800000000000) == 0x7ff2800000000000
        abort();
    }
    return 0x7ff2800000000003;
}

produces:

foo:
        shr     rdi, 47
        cmp     edi, 65509
        je      .LBB0_2
        movabs  rax, 9219572124669181952 ; 0x7ff2800000000000
        add     rax, 3
        ret
.LBB0_2:
        push    rax
        call    abort@PLT

where the movabs + add could trivially be just movabs rax, 9219572124669181955, as the movabs ends up being used only here.

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: dzaima (dzaima)

https://c.godbolt.org/z/GEb9G3bMq

This C code, compiled with -O3:

#include <inttypes.h>
#include <stdlib.h>
uint64_t foo(uint64_t x) {
    if (x >> 47 == 0xffe5) { // equivalent to (x & 0xffff800000000000) == 0x7ff2800000000000
        abort();
    }
    return 0x7ff2800000000003;
}

produces:

foo:
        shr     rdi, 47
        cmp     edi, 65509
        je      .LBB0_2
        movabs  rax, 9219572124669181952 ; 0x7ff2800000000000
        add     rax, 3
        ret
.LBB0_2:
        push    rax
        call    abort@<!-- -->PLT

where the movabs + add could trivially be just movabs rax, 9219572124669181955, as the movabs ends up being used only here.

[topperc]

I guess ConstantHoisting was trying to share 9219572124669181952 between the icmp and the return, but the icmp got optimized a different way.

Maybe the cost model for immediates needs to recognize the and+icmp pattern so ConstantHoisting will ignore it.

[dzaima]

Related open previous issue of mine that it sounds like that approach would also solve - #62145 (I'm really just stress-testing LLVM's shift canonicalization & 64-bit literals, hah; for reference all of these reported issues of mine are from NaN-boxing operations)