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

noalias on a Box doesn't seem to have an impact when compiling without -C panic=abort #95323

Open
jrmuizel opened this issue Mar 26, 2022 · 6 comments
Labels
A-box Area: Our favorite opsem complication A-codegen Area: Code generation C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jrmuizel
Copy link
Contributor

I tried this code:

struct Foo {
    x: i32
}
#[inline(never)]
fn function2() { println!("foo"); }

#[inline(never)]
fn function1() -> Box<Foo> { Box::new(Foo { x: 4}) }

pub fn foo() {
    let foo: Box<_> = function1();
    let value1 = foo.x;
    function2();
    let value2 = foo.x;
    assert_eq!(value1, value2);
}

I expect the assert_eq! to be compiled away. However, this only happens with -C panic=abort.

I'm using rustc 1.61.0-nightly (c84f39e 2022-03-20)

@RalfJung
Copy link
Member

Possibly related: #46515

@ldm0
Copy link
Contributor

ldm0 commented Jul 30, 2022

Cannot reproduce with nightly rust: https://godbolt.org/z/M5vvsbGnK

@RalfJung
Copy link
Member

Cc @Nilstrieb

@nikic
Copy link
Contributor

nikic commented Jul 30, 2022

This always worked with -C opt-level=3 but failed (and still fails) with -C opt-level=2.

@Noratrieb
Copy link
Member

Noratrieb commented Jul 30, 2022

I think LLVM inlined the function anyways and that's why it's not reproducible anymore (even with -Zbox-noalias=no). Interestingly, if the function is made truly opaque my passing a function pointer instead, the assert is not optimized away with -Zbox-noalias=no, but it is optimized away with -Zbox-noalias=yes. So this indeed seems like a case where noalias on box improves codegen.

Edit: It's obviously not inlined for codegen as the assembly shows the call, but there seems to be some smarter analysis going on.

@nikic
Copy link
Contributor

nikic commented Jul 30, 2022

@Nilstrieb Yes, LLVM infers that the return value is noalias in this case (noinline does not affect IPO inference passes).

@Enselic Enselic added A-codegen Area: Code generation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed needs-triage-legacy labels Aug 9, 2024
@workingjubilee workingjubilee added the A-box Area: Our favorite opsem complication label Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-box Area: Our favorite opsem complication A-codegen Area: Code generation 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

8 participants