Bitv indexing does not inline static values

[huonw]

#![crate_type = "lib"]

pub fn foo(x: &std::collections::Bitv) -> bool {
    x[0]
}

With --opt-level=3:

_ZN3foo20h70da181d4ab1acbaeaaE:
    .cfi_startproc
    cmpq    %fs:112, %rsp
    ja  .LBB0_2
    movabsq $8, %r10
    movabsq $0, %r11
    callq   __morestack
    retq
.LBB0_2:
    pushq   %rax
.Ltmp0:
    .cfi_def_cfa_offset 16
    cmpq    $0, 24(%rdi)
    je  .LBB0_5
    cmpq    $0, 8(%rdi)
    je  .LBB0_6
    movq    (%rdi), %rax
    movq    _ZN3bit5FALSE20h4511a5a4abbc9859osaE@GOTPCREL(%rip), %rcx ; A
    testb   $1, (%rax)
    cmovneq _ZN3bit4TRUE20h4511a5a4abbc9859ksaE@GOTPCREL(%rip), %rcx
    movb    (%rcx), %al
    andb    $1, %al ; B
    popq    %rdx
    retq
.LBB0_5:
    movq    _ZN3bit4Bitv3get14_MSG_FILE_LINE20hefeb803ecea053eeLAaE@GOTPCREL(%rip), %rdi
    callq   _ZN9panicking5panic20hb082300345003b24XUlE@PLT
.LBB0_6:
    leaq    .Lconst2(%rip), %rdi
    xorl    %esi, %esi
    xorl    %edx, %edx
    callq   _ZN9panicking18panic_bounds_check20h46462e0c27f8d7d1tWlE@PLT
.Ltmp1:
    .size   _ZN3foo20h70da181d4ab1acbaeaaE, .Ltmp1-_ZN3foo20h70da181d4ab1acbaeaaE
    .cfi_endproc

In particular, there's the two ...mov...q _ZN3bit5...20h4511a5a4abbc9859osaE@GOTPCREL(%rip), %rcx lines, which are loading the addresses of TRUE and FALSE respectively. In the best case, the [] notation on a bitv will not do this since TRUE and FALSE truly are constants and are OK to inline (alternatively, it could just avoid doing the hack to use Index and use a by-value index instead).

[Aatch]

Hmm, looks like the issue is that because indexing returns pointers to the global values LLVM can't inline them into user code. It doesn't actually know the real values. This can be confirmed by using lto, which gives LLVM access to the values.

[Mark-Simulacrum]

std::collections::Bitv no longer exists, though I think the general issues noted here are still present. Is this just a case of LTO would let this happen, and without it, there's probably nothing we can do?

[steveklabnik]

With no response to @Mark-Simulacrum , I'm guessing this is true. Closing.