<div dir="ltr"><div dir="ltr">On Mon, Apr 11, 2022 at 12:14 PM Aaron Ballman via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</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">On Mon, Apr 11, 2022 at 10:50 AM Joerg Sonnenberger via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br>
><br>
> joerg added a comment.<br>
><br>
> The patch contains at least one user visible change that would be quite surprising: it is no longer possible to intentionally set a break point on `std::move`.<br>
<br>
Thank you, that is a really good point. It would be a surprise to set<br>
a breakpoint on the code I can see in debug mode (-O0 -g) and never<br>
hit the breakpoint.<br></blockquote><div><br></div><div>The same is true of `std::strlen`: if it is builtin'ed, then you don't get a call instruction. This is perfectly expected and natural.</div><div><a href="https://godbolt.org/z/jYzTM4a7c">https://godbolt.org/z/jYzTM4a7c</a><br></div><div>Passing -fno-builtin successfully disables the optimization for std::strlen. It should also disable the proposed optimization for std::move.</div><div><br></div><div>Contra Aaron, I do not see <i>any difference at all</i> between what happens today for std::strlen and what's proposed to happen tomorrow for std::move.  I don't think std::move is somehow "more advanced" or "more STL'ish" or "more C++'ish" than std::strlen. They're both part of the standard library, and the compiler in hosted mode is allowed to assume it knows what they do — but in freestanding mode (when -fno-builtin is passed) the compiler should <i>not</i> assume it knows what they do.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Thinking more about it, what about a slightly different implementation strategy? Provide a compiler built-in `__builtin_std_move`. If it is present, libc++ can alias it into `namespace std` using regular C++.</blockquote><div><br></div><div>FWIW, Joerg, I don't understand this suggestion. By what means can libc++ "alias [a compiler builtin] into namespace std"? The only thing I have imagined so far is something like</div><div>    inline auto move(auto&& t) { return __builtin_std_move(t); }</div><div>but that would defeat the whole purpose of adding the builtin. The point of adding the builtin is to eliminate the cost of instantiating+codegenning+inlining, a whole new function for every call.</div><div>In C you could get away with</div><div>    #define move(x) __builtin_std_move(x)</div><div>but that's a non-starter in C++, because namespaces.</div><div><br></div><div>–Arthur</div></div></div>