[llvm-bugs] [Bug 48238] New: standard library APIs missing noalias on rvalue references

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=48238

            Bug ID: 48238
           Summary: standard library APIs missing noalias on rvalue
                    references
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: gonzalobg88 at gmail.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

According to the wording and notes in [res.on.arguments]/1.3, standard library
APIs taking rvalue references arguments can assume that these do not alias. 

When looking at: https://godbolt.org/z/G8ejKb


#include <utility>
int fails(int* p) {
    int&& i = std::move(std::move(*p));
    return i;
}
int works(int * __restrict p) {
    return *p;
}

the last call to `std::move` in "fails" takes an rvalue reference, and its
argument should be `noalias`, which LLVM attributor pass should be able to
propagate up to `p`.

However, the generated IR is missing no-alias.

I don't think the standard guarantees that rvalue references are always no
alias, but the standard library does guarantee that for all its APIs. 

The simplest solution I can imagine would be to add a [[__std_lib_api__]]
builtin attribute that adds `noalias` to all rvalue reference arguments of a
function. We'd need to implement the argument, and add it to libc++. 

Richard, Eric, thoughts? 

To me this wording looks extremely powerful, but from
https://cplusplus.github.io/LWG/issue1204 I don't know if this is intended or
not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201120/e20b6adc/attachment.html>