220 36345 article Path: news.gmane.org!.POSTED!not-for-mail From: Antony Polukhin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Sub-objects and their copy ellision Date: Mon, 25 Dec 2017 21:12:15 +0300 Lines: 312 Approved: news@gmane.org Message-ID: References: <1c6eff77-d71f-4dd7-8c13-f609460a03f0@isocpp.org> <3ec0bd22-b228-4026-bb49-aec5102918c7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1140f4b42b3af105612e1bd4" X-Trace: blaine.gmane.org 1514225420 16152 195.159.176.226 (25 Dec 2017 18:10:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 25 Dec 2017 18:10:20 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDR7DZXHY4MRBAH7QTJAKGQEEQPJHIQ@isocpp.org Mon Dec 25 19:10:15 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTXCZ-0003wK-Al for gclcip-std-proposals@m.gmane.org; Mon, 25 Dec 2017 19:10:15 +0100 Original-Received: by mail-lf0-f69.google.com with SMTP id t13sf8374856lfe.2 for ; Mon, 25 Dec 2017 10:12:18 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1514225538; cv=pass; d=google.com; s=arc-20160816; b=PGSJM65UAYKq3UMCUN0V7/28JbNNB0tAVX5SVYG2nMvEC4VyAmrrjK6n99WYVtBTUd UdaglCdVvHbgpRhghIbsoLcPSlFEhroubMP/SVxYsfexX04iIXyjz0nyFWQ+VwLV5kxa uYYCHiP4o7E8Gt9wkqttSpNVzNKDeab/S/f4+LXhOr5jR9mYxsKM3y6lC3fc/jqcZEDa HYy5ijMAI3EkrGMQ1E4NNpW1X2JzyNmZJu0vXFydhaRbX/AB2mzwclWBYSQ88Y1fS/AO U+EnqrBHOhXQTxHhJH+hdMMoePLkO1mdQIcrqSb1UlI6GFJ1GvuVPkpRtRCvyJoXR+CF slmA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=dYV9PQktLZ+Juzg7LC+D/fno+gsRsDcZK0W6rxzvr+k=; b=IocTrtbA6C2BvbEaSICj2kOm0kAs+KhYx/JlHL0L6ITKLGRqdWwHwLzOxfhn/ARxP1 Zt3qoJoDHj3JNc+Go09H2r6lAZdqIPvg3lDCGKqe4D9ypeRGzFoAx6jTP/S8nQ6GNa0f pf/ZktS8nTfxTYr9g3c/q34BYXKLNzaHt3bc2bbVENDP+Lbyt2EELb/jnFNaPP+wWfse N5GWsEVw5IspFa0vjXkq+McEwzoEhIrwJYkJ+6/51E3wKhGuVsYMVonuVlo4oVTsHKRt /Qkzg6vto0hmeEZELq1nsMEHvOJmz0JEJEo9Ajb7htro+u/kmEWBNob/5iunKcaaXUU6 lgTg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oNjksLV3; spf=pass (google.com: domain of antoshkka@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=antoshkka@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=dYV9PQktLZ+Juzg7LC+D/fno+gsRsDcZK0W6rxzvr+k=; b=tSqW9ww78ERfaKC/ZrGiSQdnzi1oepXHVuKJMu2gRDlfjZYjvWiLOkbH/eaYRcDB02 /wwKVq1deqsq2C1zuE46Za10refkkWqw2dpcdzbiL6xqHQ7wKLJ0dJyeJodYj0oabV5A Pr0QUiwswBM5YuzB9bJ4DdmZmOfJ1O/zeouyweZJZhE9J3ZmftGDkp1atn2ws3Zmuxwy OrpwLxK1Zrg3dLIwgl2PemO25OUxOjWsmy2hbP/KX4Lhh3ZxIq21QLnk75ZwQoT8FjTq UE4fEioJGx8A2XTHylGp/cwlzmTWRVU09+fi9hESVF30OG2JlnkOjtHbotG7ebRaOMVG ER5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=dYV9PQktLZ+Juzg7LC+D/fno+gsRsDcZK0W6rxzvr+k=; b=WHohtyrc8UkaMxD1EWRpdrDJLNlC8oxwxCVWsSP0kqsbOqRy4zOBwHLfT+5I2x04PG BvsohdITW8hEBYGGTByDlGDDJ/sWTDYG3GjCdHtkRfRbQcF+vdQlh3+/ODHwYt1mxD3Z qyHBkEz5J3o3g67NzJjj8VFo2AyKqn4xxvPG8zyH23QXiPC5A9lv+hxNh3N1/QCuUMFE Eae3nhyXBmTOZ4w8Anq2c2tD9ON2h3RQNitCRQ7z+EwjlsfnLGsxpDbtok8Esbz8+bhK TCS1Xr6R4N17FJA+w3bSXE+hphaQW3iMNri8jbEcBy1aGDolJSK5/1viEh4jDZzvFd7L Cpaw== X-Gm-Message-State: AKGB3mJjSdhpnQnGRqLGn68PiZYnQhwKfFaBH50eS9tzQWnWyWfTd46t cTdVg/ObSEFvokEFe/hj53kTmA== X-Google-Smtp-Source: ACJfBotbfg3zHBxnPjk4viRdI1vTQiK0KvxoOk2P8yLl8luHYiZUHo8SzRva1cpDaqumQ/auLJ0bag== X-Received: by 10.46.66.10 with SMTP id p10mr1621486lja.39.1514225538150; Mon, 25 Dec 2017 10:12:18 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.46.61.11 with SMTP id k11ls1184748lja.6.gmail; Mon, 25 Dec 2017 10:12:16 -0800 (PST) X-Received: by 10.46.25.217 with SMTP id 86mr14026892ljz.145.1514225536209; Mon, 25 Dec 2017 10:12:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1514225536; cv=none; d=google.com; s=arc-20160816; b=wS0VcwZAOqQDsA+Ct0gesxFsO+NrFVGlhmKbn+TrfKW+bCOUkmMzfo/ro57LkgFVNa q2mkAJQe9chcNVm6drodsZ0GvVkYDmVZjLQyXvPEdqqTujiUgLd1AHVS1YU8J/5y2rJT AtZuwl3zcfdzqRc9esI5xsbXnb4txW2t57qch3E5iFtMO3xCC4U9eigJH2ffqCBoFjmt ZoS2BRKP8fIkzOg9T54hJxCKAqzaLSwaVCWMDgBZAy/Vdw9xxZwrg+xG9HAAaStzcaac 9Aa4V3Zng+08kDhsP6kCF6IJw9yxCx5kxhF51BwOmP1/o7Y02/SfTwbpvpMKGh+jZVJ3 8F7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=NUpZ0hw3SURIB7T2AAx5CCIyJSspz0AU7vdnex0uOlc=; b=GGNxh9nUc11cFyI2fYPl7aZKCiZNEyb9nBctBtM67+x9QLD3wWDAi67ATTWdNmXsUM mmCVUc2P7uAn4Pqj7kYN8Aurt44FNUk9M4BPPWqkbHCFnY+LEEo6Y20Vw+6gRVl18+Er 2x/Ro/gxTiGfWhgzyN9gWxBVB/BhrW3nWTgbgobvv4TjJklrSqTvY3O+1KZjw9yc/AIm +awj3pr/x8eC8D2QsAB9eBz2nQXwtS7v0QBkYlx8RhMX1bB5m2XBwLKHgDipa8Di/ELf 9/KVTb5hWQ4J3YPlVLyhwa9UUBAtTPbQKJ9orVaZHn51frYCJ5euQ5PA4cfpv0ySRGOu hT0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oNjksLV3; spf=pass (google.com: domain of antoshkka@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=antoshkka@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id i67sor927213lfb.108.2017.12.25.10.12.16 for (Google Transport Security); Mon, 25 Dec 2017 10:12:16 -0800 (PST) Received-SPF: pass (google.com: domain of antoshkka@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.25.216.223 with SMTP id r92mr2136951lfi.124.1514225535759; Mon, 25 Dec 2017 10:12:15 -0800 (PST) Original-Received: by 10.25.208.203 with HTTP; Mon, 25 Dec 2017 10:12:15 -0800 (PST) In-Reply-To: <3ec0bd22-b228-4026-bb49-aec5102918c7@isocpp.org> X-Original-Sender: antoshkka@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oNjksLV3; spf=pass (google.com: domain of antoshkka@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=antoshkka@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:36345 Archived-At: --001a1140f4b42b3af105612e1bd4 Content-Type: text/plain; charset="UTF-8" On Dec 20, 2017 04:06, "Nicol Bolas" wrote: <...> Just within this thread, we have identified a number of limitations on what you can do with such objects. Let's not go further than merely what you've already agree to: destruction of subobjects and layout. That is, this optimization is not possible if any of the following is true: 1) The containing type has a non-defaulted destructor. 2) The containing object is not passed to another function by pointer or reference, since that requires the object's layout to be consistent with what the standard says. 3) The user of the containing object does not do anything layout-specific itself. Note that this is almost certainly* not* a complete list. It's merely the ones talked about thus far; there are almost certainly others. Since late November paper concentrates on cases when the callee is inlined. In that case there's no need to mess with the object layout. But please, wait for a moment and read further. I know that this point rises even more questions. Item #2 is particularly important. Why? Because that rules out calling* any member functions*, since all non-static member functions take the object by pointer. And that requires the object's layout to be consistent with its definition. Notice that "Motivating example #2" doesn't qualify for this, since we call a function on the object. That requires it to have a certain layout. So, how much real code actually qualifies for such elision? Because here's the thing the person behind that proposal just doesn't get. His proposal* doesn't work*. It does not solve the problem. Why? Because compilers can't do it in so many of these cases. RVO was very reliable; when compilers offered it, it worked for any case of returning a prvalue. NRVO is pretty reliable; declare the variable at the top of the function, return it whenever, and you're almost guaranteed to get the optimization. That's true. But let me put it other way around. Compilers could do devirtualization. Does this optimization reliable? No, it is very dependent on the compiler abilities and flags. Does the C++ Standard forbids that optimization? No, because it's an optimization and users may benefit from it. Just treat optimization from the "subobject copy elision" paper as some random optimization: not something you could rely on, but something that may help if compiler is clever enough. What are the guidelines for getting this proposal's optimizations? What circumstances stop it, and what can be done to avoid them? Because here's the thing: if I do this: string foo() { string str; str = ...; return str; } If I do that, and I* don't* get elision, it's still fine. Why? Because I still get automatic move support. `str` in the return statement is a reference to an automatic variable in the function's scope, so it is moved from. I may not have gotten the best answer, but I got a good enough one. In this case: string foo() { pair pr = ...; return pr.second; } What happens if this doesn't get elided? Well, you get a copy. The only way to get a move is to ask for it: `return std::move(pr.second)`. So the proposal actually* encourages bad code*, on the assumption that the compiler will swoop in and save you. You've got that impression from the assumption that the optimization is something you could rely on, which is not true. But the example with std::move that disables the copy elision is a good catch. I've been thinking on that problem a lot a few weeks ago and suddenly came up with a more generic solution: http://apolukhin.github.io/papers/ultimate_copy_elision.html I'd be grateful if you and other volunteers could take a look at it. It addresses most of the above comments. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKqmYPbdMjxUOp9u%2BErcx%2BeYjvUJvAn%2BCZe5EDpgGd4vaz47ag%40mail.gmail.com. --001a1140f4b42b3af105612e1bd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Dec 20, 2017 04:06, "Nicol Bolas" &= lt;jmckesson@gmail= ..com> wrote:
<...>
Just within this thread, we have identified a number o= f limitations on what you can do with such objects. Let's not go furthe= r than merely what you've already agree to: destruction of subobjects a= nd layout. That is, this optimization is not possible if any of the followi= ng is true:

1) The containing type has a non-defau= lted destructor.
2) The containing object is not passed to anothe= r function by pointer or reference, since that requires the object's la= yout to be consistent with what the standard says.
3) The user of= the containing object does not do anything layout-specific itself.

Note that this is almost certainly not a complete = list. It's merely the ones talked about thus far; there are almost cert= ainly others.
<= br>
Since late November paper concentrates on cases = when the callee is inlined. In that case there's no need to mess with t= he object layout. But please, wait for a moment and read further. I know th= at this point rises even more questions.
=




<= /div>
Item #2 is particularly important. Why? Because that rules out ca= lling any member functions, since all non-static member functions ta= ke the object by pointer. And that requires the object's layout to be c= onsistent with its definition.

Notice that "<= span style=3D"display:inline;float:none;background-color:transparent;color:= rgb(34,34,34);font-family:"Arial","Helvetica",sans-seri= f;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;lett= er-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text= -transform:none;white-space:normal;word-spacing:0px">Motivating example #2&= quot; doesn't qualify for this, since we call a function on the object.= That requires it to have a certain layout.

So, how much = real code actually qualifies for such elision?

Bec= ause here's the thing the person behind that proposal just doesn't = get. His proposal doesn't work. It does not solve the problem. W= hy?

Because compilers can't do it in so many o= f these cases. RVO was very reliable; when compilers offered it, it worked = for any case of returning a prvalue. NRVO is pretty reliable; declare the v= ariable at the top of the function, return it whenever, and you're almo= st guaranteed to get the optimization.
=

That's true. But le= t me put it other way around.

Compilers could do devirtualization. Does this optimization reliable?= No, it is very dependent on the compiler abilities and flags. Does the C++= Standard forbids that optimization? No, because it's an optimization a= nd users may benefit from it.

Just treat optimization from the "subobject copy elision" p= aper as some random optimization: not something you could rely on, but some= thing that may help if compiler is clever enough.


What are = the guidelines for getting this proposal's optimizations? What circumst= ances stop it, and what can be done to avoid them?

Because here's the thing: if I do this:

string foo()
{
=C2=A0 string str;
=C2=A0 str =3D ...;
=C2=A0 return str;
}

If I do that, and I don't get elision, it's = still fine. Why? Because I still get automatic move support. `str` in the r= eturn statement is a reference to an automatic variable in the function'= ;s scope, so it is moved from. I may not have gotten the best answer, but I= got a good enough one.

In this case:
string foo()
{
=C2=A0 pair<string, <= /span>string> pr =3D ...;
=C2=A0 return pr.s= econd;
}

What happens if this doesn't g= et elided? Well, you get a copy. The only way to get a move is to ask for i= t: `return std::move(pr.second)`.

So the proposal actually encourages bad c= ode, on the assumption that the compiler will swoop in and save you.

You've got t= hat impression from the assumption that the optimization is something you c= ould rely on, which is not true.

=
But the example with std::move that disables the copy elision is a goo= d catch. I've been thinking on that problem a lot a few weeks ago and s= uddenly came up with a more generic solution: http://apolukhin.github.io/pape= rs/ultimate_copy_elision.html

I'd be grate= ful if you and other volunteers could take a look at it. It addresses most = of the above comments.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKqmYPbdMj= xUOp9u%2BErcx%2BeYjvUJvAn%2BCZe5EDpgGd4vaz47ag%40mail.gmail.com.
--001a1140f4b42b3af105612e1bd4-- .