Skip to content
New issue

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

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

Already on GitHub? Sign in 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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