Missed optimization: references from pointers aren't treated as noalias

[mjbshaw]

The following code results in a being dereferenced again for the return value: (https://godbolt.org/z/YnrzMa3oj)

pub unsafe fn g(a: *mut i32, b: *mut i32) -> i32 {
  *a = 0;
  *b = 1;
  return *a;
}

That is to be expected. In contrast, the same function with references avoids the load: (https://godbolt.org/z/YnrzMa3oj)

pub fn g_ref(a: &mut i32, b: &mut i32) -> i32 {
  *a = 0;
  *b = 1;
  return *a;
}

However, if we change the code to the following: (https://godbolt.org/z/YnrzMa3oj)

pub fn g(a: *mut i32, b: *mut i32, x: *const i32) {
  let a = &mut *a;
  let b = &mut *b;
  *a = 10;
  *b = 11;
  return *a;
}

then the extra dereference is not optimized out as it should be, because do not emit anything like noalias inside functions.

[bluss]

It might be due to /issues/31681

[aidanhs]

Do you have a play link demonstrating noalias taking effect? AFAIK noalias annotations were completely removed after 1.7.0 due to the llvm bugs.

Here is your foo with some bits and pieces to defeat whole-program optimisation:

use std::process;

fn main() {
    let r1 = foo(&mut 1, &mut 2, &3);
    let r2 = foo(&mut 1, &mut 2, &4);
    process::exit(r1 + r2)
}

#[inline(never)]
pub fn foo(a: &mut i32, b: &mut i32, x: &i32) -> i32 {
  *a = *x;
  *b = *x;
  *a
}

https://is.gd/NsngDd

If you compile that in release mode and look at the LLVM IR, you'll see that foo does not have noalias annotations and performs the store twice.

[mjbshaw]

Here's a demo: https://godbolt.org/g/pSj51i

pub fn foo(a: &mut i32, b: &mut i32, x: &i32) {
  *a = *x;
  *b = *x;
}

compiles into:

example::foo:
        push    rbp
        mov     rbp, rsp
        mov     eax, dword ptr [rdx]
        mov     dword ptr [rdi], eax
        mov     dword ptr [rsi], eax
        pop     rbp
        ret

[aidanhs]

Right, sorry, I was being dim - you're referring to the load only happening once.

This is probably because immutable references are marked as readonly in llvm (take a look at the debug llvm IR of my example). If you make x be &mut in your example, you'll see it does do the load twice despite it theoretically giving more information in this function (if all three were noalias, as implied by &mut, llvm could infer that x is readonly). Given this deoptimisation, noalias annotations must not be being emitted at all which agrees with my understanding of the current situation.

Your last example has all pointer arguments which do not get annotated, even if they're const. I don't know what the current state of annotating local variables is in rust, which is what that would require.

[mjbshaw]

I don't think the readonly attribute makes a difference here. Or at least, it shouldn't. LLVM documents it as:

On an argument, this attribute indicates that the function does not write through this pointer argument, even though it may write to the memory that the pointer points to.

It clearly states that the memory may be written to (but only through a different pointer, not through the argument marked as readonly). Thus, it should have to load the pointer twice.

AFAIK, this optimization should only be possible if a, b, or x are marked as noalias.

Indeed, if you compile the following C code:

void foo(int *a, int *b, const int* x) {
    *a = *x;
    *b = *x;
}

The generated LLVM IR marks x as readonly but still loads it twice (which is to be expected):

; Function Attrs: norecurse nounwind ssp uwtable
define void @foo(i32* nocapture, i32* nocapture, i32* nocapture readonly) #0 {
  %4 = load i32, i32* %2, align 4, !tbaa !2
  store i32 %4, i32* %0, align 4, !tbaa !2
  %5 = load i32, i32* %2, align 4, !tbaa !2
  store i32 %5, i32* %1, align 4, !tbaa !2
  ret void
}

Actually, your point about making x an &mut hints at the reason why the extra load is optimized out in the first place: if x is an immutable reference, it is marked as noalias; if it's a mutable reference, then it is not marked as noalias (edit: on second thought, is it valid to have two readonly noalias pointers that alias? They're both noalias, but at the same time neither will be used to modify the data... I'm not actually sure how LLVM would respond in this case). I believe this is due to the issue bluss linked to: #31681

However, it doesn't answer the question why safe_x doesn't get marked as noalias, despite being an immutable reference. I believe safe_x should be marked as noalias.

[bluss]

Good issue. noalias on &mut is unrelated, sorry for the misdirection.

I'd look at

1. Is rustc emitting noalias where it can? (Or other relevant metadata)
2. Is this metadata lost in some optimization pass? (Example: Extra null check in slice iterator's .next().is_none() #37945)

I'm not sure there is a place where noalias can be placed

For this code:

#![crate_type="lib"]

pub fn foo(a: &mut i32, b: &mut i32, x: *const i32) {
    unsafe {
        let r = &*x;
        *a = *r;
        *b = *r;
    }
}

This is produced (rustc --emit=llvm-ir noalias.rs). It looks like there is no place where noalias can be used, except if it were back traced to the function argument for this particular function body.

; ModuleID = 'noalias.cgu-0.rs'
source_filename = "noalias.cgu-0.rs"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

; Function Attrs: uwtable
define void @_ZN7noalias3foo17h1c56d659e6e1ab4bE(i32* dereferenceable(4), i32* dereferenceable(4), i32*) unnamed_addr #0 {
entry-block:
  %_0 = alloca {}
  br label %start

start:                                            ; preds = %entry-block
  %3 = load i32, i32* %2
  store i32 %3, i32* %0
  %4 = load i32, i32* %2
  store i32 %4, i32* %1
  ret void
}

attributes #0 = { uwtable }

[aidanhs]

This may be what you're looking for - #16515

[sanmai-NL]

Perhaps someone can tag this issue as performance related? How can non-maintainers help to do such routine work? I vaguely remember @TimNN doing this a lot for issues here.

[steveklabnik]

How can non-maintainers help to do such routine work?

Unfortunately, GitHub doesn't let anyone do issue triage without having a commit bit, it's kind of annoying.

If you email me a list of issues and changes that should be made, I can manually do it on your behalf, for now. It's not great. I'd like to solve this somehow, but there's so much work to do...

[sanmai-NL]

Off-topic
@steveklabnik:
It's not so much a request from me, but a general question. Perhaps there is some way using the GitHub API and crowd sourced tagging.

[nox]

So in which way is this issue not a duplicate of #16515?

Cc @rust-lang/wg-codegen