<div dir="ltr"><div dir="ltr">On Wed, 29 Jul 2020 at 14:42, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, 29 Jul 2020 at 12:52, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>




<div>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Clang IRGen currently doesn’t mark indirect parameters as <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">noalias</code>.  Considerations:</p>

<ul>
<li><p dir="auto">A lot of targets don’t pass struct arguments indirectly outside of C++, but some do, notably AArch64.</p></li>
<li><p dir="auto">In a pure C world, we would always be able to mark such parameters <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">noalias</code>, because arguments are r-values and there’s no way to have a pointer to an r-value.</p></li>
<li><p dir="auto">ObjC <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">__weak</code> references can have pointers to them from the ObjC runtime.  You can’t pass a weak reference immediately as an argument because <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">__weak</code> is a qualifier and qualifiers are ignored in calls, but you can put one in a struct and pass that, and that struct has to be passed indirectly.  Arguably such a parameter cannot be <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">noalias</code> because of the pointer from the runtime, but then again, ObjC code isn’t allowed to directly access the weak reference (it has to call the runtime), which means that no accesses that LLVM can actually see violate the <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">noalias</code> restriction.</p></li>
<li><p dir="auto">C++ parameters of non-trivially-copyable class type cannot be marked <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">noalias</code>: it is absolutely permitted to escape a pointer to <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">this</code> within a constructor and to replace that pointer whenever the object is moved.  This is both well-defined and sometimes useful.</p></li>
<li><p dir="auto">It’s actually possible to escape a pointer to <em>any</em> C++ object within its constructor, and that pointer remains valid for the duration of the object’s lifetime.  And you can do this with NRVO, too, so you don’t even need to have a type with non-trivial constructors, as long as the object isn’t copied.  Note that this even messes up the C case, which is really unfortunate: arguably we need to pessimize C code because of the possibility it might interoperate with C++.</p></li>
<li><p dir="auto">But I think there’s an escape hatch here.  C++ has a rule which is intended to give implementation extra leeway with passing and returning trivial types, e.g. to pass them in registers.  This rule is C++ [class.temporary]p3, which says that implementations can create an extra temporary object to pass an object of type <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">X</code> as long as “each copy constructor, move constructor, and destructor of X is either trivial or deleted, and X has at least one non-deleted copy or move constructor”.  This object is created by (trivially) copy/move-initializing from the argument/return object.  Arguably we can consider any type that satisfies this condition to be <em>formally</em> copied into a new object as part of passing or returning it.  We don’t need to <em>actually</em> do the copy, I think, we just need to consider a copy to have been done in order to formally disrupt any existing pointers to the object.  (Although arguably you aren’t allowed to copy an object into a new object at the original object’s current address; it would be an unfortunate consequence of this wording if we had to either forgo optimization or do an unnecessary copy here.)</p></li>
</ul>

<p dir="auto">Thoughts?<br></p></div></div></div></blockquote><div>From a high level: I think the C++ language semantics *should* permit us to assume that objects passed by value to functions, and objects returned by value from functions (in which category I include *this in a constructor), are noalias.</div></div></div></blockquote><div><br></div><div>... specifically in the case where they're trivially copyable and the implementation was permitted to make a copy. In the case of non-trivial copy operations, I think we probably should be forced to assume that the address of the object may have escaped.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I think concretely, the escape hatch doesn't stop things from going wrong, because -- as you note -- even though we *could* have made a copy, it's observable whether or not we *did* make a copy. For example:</div><div><br></div><div>#include <stdio.h><br><br>struct A {<br>    A(A **where) : data{"hello world"} { *where = this; }<br>    char data[65536];<br>};<br>A *p;<br><br>[[gnu::noinline]]<br>void f(A a) {<br>    for (int i = 0; i != sizeof(A::data) - 2; ++i)<br>        p->data[i+1] = a.data[i];<br>    puts(a.data);<br>}<br><br>// elsewhere, perhaps compiled by a smarter compiler that doesn't make a copy here<br>int main() { f({&p}); }<br></div><div><br></div><div>I think it's valid for this program to print "hello world" or for it to print "hhhhhhhhhhhhh...", but it's not valid to (eg) turn the copy loop into a memcpy with undefined behavior.</div><div><br></div><div>As it happens, we do actually make a redundant copy here when performing the call to `f`, which seems wasteful. And so do GCC and ICC, which means the 'noalias' would actually be correct here considering only the behavior of those compilers. So in principle we could address this in the ABI by saying that the copy is mandatory. But I don't think we should -- I think the above code should have undefined behavior because it accesses a function parameter through an access path not derived from the name of the function parameter.</div><div><br></div><div>We do have some wording in the standard that tries to give aliasing guarantees in some of these cases, but does so in a way that's not really useful. Specifically, [class.cdtor]p2: "During the construction of an object, if the value of the object or any of its subobjects is accessed through a glvalue that is not obtained, directly or indirectly, from the constructor’s this pointer, the value of the object or subobject thus obtained is unspecified." (I mean, thanks for trying, but that's not all the cases, and "the value is unspecified" is not enough permission.)</div><div><br></div><div>Maybe we could mark such cases as 'noalias', behind a known-non-conforming flag. The question would then be whether we enable it by default or not.</div></div></div>
</blockquote></div></div>