Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

-C inline-threshold is ignored by LLVM when optimizing for size, while llvm-args=-inline-threshold works #61088

Closed
neivv opened this issue May 23, 2019 · 4 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@neivv
Copy link

neivv commented May 23, 2019

pub fn copy_u32(input: &[u8; 4], output: &mut [u8; 4])  {
    let a = &input[..4];
    let b = &mut output[..4];
    for b in b.chunks_exact_mut(4) {
        b.copy_from_slice(a);
    }
}

Complied with -C opt-level=s -C inline-threshold=300 produces (same as just -C opt-level=s)

example::copy_u32:
        mov     rax, rsi
        mov     rdx, rdi
        mov     esi, 4
        mov     ecx, 4
        mov     rdi, rax
        jmp     qword ptr [rip + core::slice::<impl [T]>::copy_from_slice@GOTPCREL]

Complied with -C opt-level=s -C llvm-args=-inline-threshold=300 produces

example::copy_u32:
        mov     eax, dword ptr [rdi]
        mov     dword ptr [rsi], eax
        ret

(Godbolt link)

The cause appears to be that LLVM keeps using a separate inlining threshold from the "primary" one given by rustc on functions with optsize attribute, but only when it didn't receive -inline-threshold itself.

Fixing this seems to either require converting the rustc-received argument to LLVM commandline one, or constructing a custom llvm::InlineParams structure instead of using one of LLVM-provided helper functions?

@jonas-schievink jonas-schievink added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 23, 2019
@hudson-ayers
Copy link
Contributor

I observed on rust nightly 2020-09-22 that

Compling with -C opt-level=z -C inline-threshold=300 produces a binary with a different size from -C opt-level=z -C inline-threshold=0 and a different size from -C opt-level=Z -C llvm-args=-inline-threshold=300. So it does not seem that -C inline-threshold is completely ignored (presumably because some functions end up not being marked with the optsize attribute?)

@workingjubilee
Copy link
Member

These are now identical due to recent changes to LLVM's pass manager, making this functionally a duplicate of the other issue on what to do with -Cinline-threshold.

@workingjubilee workingjubilee closed this as not planned Won't fix, can't repro, duplicate, stale Jul 6, 2022
@hudson-ayers
Copy link
Contributor

Are they now identical in that both do nothing? Or they both work the way that llvm-args=-inline-threshold used to work?

@workingjubilee
Copy link
Member

Are they now identical in that both do nothing? Or they both work the way that llvm-args=-inline-threshold used to work?

My experimentation suggests they both appear to do nothing.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants