220 36420 <2bcc2be2-fafb-4c9b-ab85-a22fca83e3d6@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Sub-objects and their copy ellision Date: Thu, 28 Dec 2017 06:37:09 -0800 (PST) Lines: 132 Approved: news@gmane.org Message-ID: <2bcc2be2-fafb-4c9b-ab85-a22fca83e3d6@isocpp.org> References: <1c6eff77-d71f-4dd7-8c13-f609460a03f0@isocpp.org> <3ec0bd22-b228-4026-bb49-aec5102918c7@isocpp.org> <924751e5-c880-42aa-95ab-99ef1050be2e@isocpp.org> <80bbb75a-2a62-537a-3733-898225325a41@technion.ac.il> <83d8a425-fd2f-41b6-9941-2a5deb27806d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_24263_1533839675.1514471829825" X-Trace: blaine.gmane.org 1514471717 18477 195.159.176.226 (28 Dec 2017 14:35:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 28 Dec 2017 14:35:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBFUDSTJAKGQEJNTNR3Q@isocpp.org Thu Dec 28 15:35:13 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUZH3-0004Lx-4N for gclcip-std-proposals@m.gmane.org; Thu, 28 Dec 2017 15:35:09 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id p197sf20335523vkf.14 for ; Thu, 28 Dec 2017 06:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=wE/w7zdqNpz3ciWGPeUPRucBJIXV9tWBeQO2+mT1fPs=; b=OQ3pgvED4b8lF40ADBY6JbaQllTYm1Wayp29HfHuUVojMuwdFUGLNV14Aj5BKIFsE1 tXXglBXmDyUy/A5tYC077Bjy7MxB7BQOPSPY0S49hhFCDr9DpOBI9dJi1BNUStTjF+Yi U0D6q3Ev5tUIro6c+NZfdJvAuzURFV0DSw/T57xMYz6fiRQqx5zK8I9e1uMzOun+Yx7F ykHm+eD2yzCRZd8b4cS5rUJsOSdQ0506rcYb1ZxQTEy1v98VljeEIMLTX4T4c4TTj1hZ Crgi8+Kh7blN0t64E7cYPSAWE6q8CLno0rc8hIZXxD/nPS1haPHmj9Nb2Iemd2rH+G7c S42A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=wE/w7zdqNpz3ciWGPeUPRucBJIXV9tWBeQO2+mT1fPs=; b=DeR4mV82AtHGxLNYtNpll+SS3nIMwrCzUgn9yFfWiBLD9pSsyBUZkQnnp7gxMDvfhk 0+op644zNyDKvf6XJE4zOmpl0uqoKrIqdlpZ7elwSm0e+NNwOS7ScANigF5EWCYBUKMO Tx9hWXZgX8n7ab+WNRAcpX+UQPpi2KQ9gGFE9jJEJRdi1uszOR7CAClNhlqVyuIYkq6Z YmHT5r8Xl855tyBNf4G6/W4NkxSZURCgAb+r+ozmY9j2xa39ffcuksaF0jn6IWrTuSLM yHuy7x3+vFzO3C/iL+7guFriBiewPNsffFDv0ry56XG7U7BgBo76kRR7Sf2IgTIvMmL5 VWdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=wE/w7zdqNpz3ciWGPeUPRucBJIXV9tWBeQO2+mT1fPs=; b=EhlYfp9TkJBKOz9pNXZBII4WIRCfxUtp6klH8eLrqeid4+MP5hLgNt5wUyvvEttF28 /XdJfoOL1qOlzTHzioCQeN8cIUrTkgp5LqerqUJOB1LR5jlwZzT4t5ewkbEdWahC+UsG Hug0YGUTknRZljq/1blhz5yLWOwZMWfC3Ax9W7JlypAe25cCm83BiIqpEnFECE9Ba66j CzmjRr9FYH/NpF6bZWP2cLhu2Vddi+Ym1MxaLn+xqDO5rOw6lyVcBiUTQqPqOMRz/EoI eqLAVK6dsN46HcINY++Eez2YS9e7wKx9eMCLJmdbRcCyTrKBkui9km+dwSf7PkLjd9t5 goDw== X-Gm-Message-State: AKGB3mK6znhLuRV0fuxtesEmXREe+Q5bmivQsv56ZCeyPKNWaBwIpaYY DVrABesBpDsFxnq0fs6iUrrZlw== X-Google-Smtp-Source: ACJfBotcsQXXpiqg0RKPLU9KiCEcGluKVBoqmNXeR6NJOUQ94Gk6LR/sCzPpF2TWG45Lfhgo2TgjPw== X-Received: by 10.31.236.69 with SMTP id k66mr14768115vkh.102.1514471831834; Thu, 28 Dec 2017 06:37:11 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.35.84 with SMTP id 78ls4074273uae.3.gmail; Thu, 28 Dec 2017 06:37:10 -0800 (PST) X-Received: by 10.31.49.200 with SMTP id x191mr2929863vkx.2.1514471830394; Thu, 28 Dec 2017 06:37:10 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@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:36420 Archived-At: ------=_Part_24263_1533839675.1514471829825 Content-Type: multipart/alternative; boundary="----=_Part_24264_1901850552.1514471829826" ------=_Part_24264_1901850552.1514471829826 Content-Type: text/plain; charset="UTF-8" On Thursday, December 28, 2017 at 2:01:25 AM UTC-5, Antony Polukhin wrote: > > 2017-12-26 18:25 GMT+03:00 Nicol Bolas >: > >> On Tuesday, December 26, 2017 at 4:05:52 AM UTC-5, Eyal Rozenberg wrote: >>> >>> On 12/25/17 8:15 PM, Nicol Bolas wrote: >>> > On Monday, December 25, 2017 at 1:12:19 PM UTC-5, Antony Polukhin >>> wrote: >>> > Why is this circumstance important enough to be /worth/ all of this >>> hassle? >>> >>> Because right now compilers are entirely-or-partially prevented from >>> applying a useful optimization in some relatively-common cases. >>> >> >> I see little evidence that these cases are indeed "relatively-common" >> enough to bother with this. >> > > I've added an example where moving out std::string produces much worse > assembly than with move elision of subobjects. Is that example convincing? > No. It demonstrates nothing about how* common* this case is. My point here was that the cases where this circumstance would be encountered, would happen within a type where the compiler could actually implement elision, and would be in a case where elision was possible within the rules we've discussed, is such a rare occurrence that it's essentially irrelevant. You can create all the artificial examples you want, but it doesn't show how often this would matter in the real world. Also, that example doesn't effectively demonstrate what the assembly would look like, since it's not actually doing elision. Elision is not the same thing as* inlining*. > It's in the "The problem is not that big" concern > http://apolukhin.github.io/papers/ultimate_copy_elision.html > > -- 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/2bcc2be2-fafb-4c9b-ab85-a22fca83e3d6%40isocpp.org. ------=_Part_24264_1901850552.1514471829826 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, December 28, 2017 at 2:01:25 AM UTC-5, Antony= Polukhin wrote:
2017-12-26 18:25 GMT+03:00 Nicol Bolas <= span dir=3D"ltr"><jmck...@gmail.com>:
On Tuesday, December 2= 6, 2017 at 4:05:52 AM UTC-5, Eyal Rozenberg wrote:
On 12/25/17 8:15 PM, Nicol Bolas wro= te:
> On Monday, December 25, 2017 at 1:12:19 PM UTC-5, Antony Polukhin = wrote:
> Why is this circumstance important enough to be /wort= h/ all of this hassle?

Because right now compilers are entirely-or-partially prevented from
applying a useful optimization in some relatively-common cases.

I see little evidence that these cases = are indeed "relatively-common" enough to bother with this.
<= /div>

I've added an example where movin= g out std::string produces much worse assembly than with move elision of su= bobjects. Is that example convincing?
<= div>
No. It demonstrates nothing about how common this= case is. My point here was that the cases where this circumstance would be= encountered, would happen within a type where the compiler could actually = implement elision, and would be in a case where elision was possible within= the rules we've discussed, is such a rare occurrence that it's ess= entially irrelevant.

You can create all the artifi= cial examples you want, but it doesn't show how often this would matter= in the real world.

Also, that example doesn't= effectively demonstrate what the assembly would look like, since it's = not actually doing elision. Elision is not the same thing as inlining.
=C2=A0
It's in = the "The problem is not that big" concern = http://apolukhin.github.io/papers/ultimate_copy_elision.html<= br>

--
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/2bcc2be2-fafb-4c9b-ab85-a22fca83e3d6= %40isocpp.org.
------=_Part_24264_1901850552.1514471829826-- ------=_Part_24263_1533839675.1514471829825-- .