From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42451 invoked by alias); 25 Jul 2018 20:04:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 42428 invoked by uid 89); 25 Jul 2018 20:04:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jul 2018 20:04:27 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1306240216EA; Wed, 25 Jul 2018 20:04:26 +0000 (UTC) Received: from localhost (unknown [10.33.36.95]) by smtp.corp.redhat.com (Postfix) with ESMTP id C95A4111DCF9; Wed, 25 Jul 2018 20:04:25 +0000 (UTC) Date: Wed, 25 Jul 2018 20:04:00 -0000 From: Jonathan Wakely To: libstdc++@gcc.gnu.org Cc: =?iso-8859-1?Q?Fran=E7ois?= Dumont , gcc-patches Subject: Re: Share ebo helper throughout lib Message-ID: <20180725200425.GE14057@redhat.com> References: <1b6ec4c9-cdf9-2b7c-f263-185e70029d54@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.2 (2017-12-15) X-SW-Source: 2018-07/txt/msg01573.txt.bz2 On 25/07/18 21:53 +0200, Marc Glisse wrote: >On Wed, 25 Jul 2018, François Dumont wrote: > >>    It has already been noticed that there are 2 ebo helpers in the >>lib. Here is a patch to use 1. >> >> >>    * include/bits/ebo_helper.h: New. >>    * include/Makefile.am: Add latter. >>    * include/Makefile.in: Regenerate. >>    * include/bits/hashtable_policy.h: Adapt. >>    * include/bits/shared_ptr_base.h: Adapt. >> >>Tested under linux x86_64. >> >>Ok to commit ? > >I don't think we support [[no_unique_address]] yet, but assuming we >soon will and we enable it also for C++03 (at least with the >__attribute__ syntax and/or in system headers), do you know if some Yes, I hope we'll have that soon. >similar helper will still be necessary, with a simpler implementation, >or if the attribute will magically get rid of it? We'll be able to replace some uses of EBO with the attribute (specifically, in std::tuple). In some places we'll want to only apply the attribute under the same conditions as we currently use the EBO, because otherwise we'd change the layout ("compressing" the member using the attribute where we previously didn't compress it). In some cases that will be OK because it's an internal implementation detail, or because we can replace e.g. _Sp_counted_deleter with _Sp_counted_deleter_v2. In other cases we must avoid any layout change (e.g. std::tuple). Concretely, we probably don't want to change the layout of the hashtable types. We could change the layout for shared_ptr _Sp_counted_xxx types (gaining some additional space savings for final types that currently can't be EBO'd) as long as we rename them to avoid the linker trying to combine incompatible definitions. So on that basis, maybe we don't want to bother changing the _Sp_ebo_helper for now.