From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97050 invoked by alias); 5 Apr 2017 15:27:24 -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 96411 invoked by uid 89); 5 Apr 2017 15:27:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:Windows-1252, HX-HELO:sk:EUR02-H, HCC:D*de X-HELO: EUR02-HE1-obe.outbound.protection.outlook.com Received: from mail-oln040092068093.outbound.protection.outlook.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (40.92.68.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Apr 2017 15:27:22 +0000 Received: from VE1EUR02FT021.eop-EUR02.prod.protection.outlook.com (10.152.12.56) by VE1EUR02HT224.eop-EUR02.prod.protection.outlook.com (10.152.13.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1005.5; Wed, 5 Apr 2017 15:27:20 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.12.58) by VE1EUR02FT021.mail.protection.outlook.com (10.152.12.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.5 via Frontend Transport; Wed, 5 Apr 2017 15:27:20 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([fe80::a806:64f0:6377:f3ea]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([fe80::a806:64f0:6377:f3ea%19]) with mapi id 15.01.1019.015; Wed, 5 Apr 2017 15:27:20 +0000 From: Bernd Edlinger To: Jakub Jelinek CC: GCC Patches , Jason Merrill , "Marc Glisse ; Jonathan Wakely" , Richard Biener , Jeff Law Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) Date: Wed, 05 Apr 2017 15:27:00 -0000 Message-ID: References: <20170405132832.GS17461@tucnak> In-Reply-To: <20170405132832.GS17461@tucnak> authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de; x-incomingtopheadermarker: OriginalChecksum:EE5D15E3C7820AB22EEBFD68E95A8BCC5DC4A15085EC8FF2DEBC06D98B3E1963;UpperCasedChecksum:5FB446CB9772A7A029C5D394562FFC225E60B0AF84D2AF2EA741D23BF42C98C1;SizeAsReceived:8197;Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-microsoft-exchange-diagnostics: 1;VE1EUR02HT224;5:yfdQluUssVR5LDGxIROLRPJvEhSRqp0iZtB0n1+ErX0m7iQAelEF67SyS/XsAi0dUMSDqlkddfH5rItVyWoK5PUWttHkJnAeCLlcxKfg9OcFLq6Pqc0iGQ+yZneC6CjMJitE0q3yRiwkrLhpG8Mkng==;24:Uzfe4q+M9ENx+H8z2qGNYu5x6ABPceKTtuoyjSv7jVvT9hDtull9kvL4opG8Px4qCEWQZZ+K/iPP+0hTbqTrM6gzc37d3kB3HYaZ846XevE=;7:ZDquOKtR75sXYaEw0R6wIP0AMHOX8WFz61ciWWZv4uyK5ShWuAHwBI4crye2Fe6HnVgHTJjUfs2vHFBCZFVKBj1dshgfD21tkL17idPG/xFJYUg0hAhSVqCeEUeOzHW2k4OnwnESnSJmKvx21+od2/2pXr9DZOZHS2lW9Ku4pLPmUAMK6iIgk3wPQKZOSy+1yt4ftUVDYku5cWjCbueOVSUXAbrr56xRna8vuxmEbCeINKYIQfCzB/zsiNpN/UofgoVPw62PQ8/04E7cxA7a5c5i5N8H2+2YsTXCOAtV53JCPNMAxh/+IR99r+mEcRxd x-incomingheadercount: 40 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:VE1EUR02HT224;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-office365-filtering-correlation-id: 0722ff82-5d61-436a-f281-08d47c383f4d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1601125374)(1603101448)(1701031045);SRVR:VE1EUR02HT224; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(444000031);SRVR:VE1EUR02HT224;BCL:0;PCL:0;RULEID:;SRVR:VE1EUR02HT224; x-forefront-prvs: 0268246AE7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <43F50C18EDEE694D8964CF6C850E14ED@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 15:27:20.2420 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT224 X-SW-Source: 2017-04/txt/msg00230.txt.bz2 On 04/05/17 15:28, Jakub Jelinek wrote: > On Wed, Apr 05, 2017 at 09:46:09AM +0000, Bernd Edlinger wrote: >> this is related to the P1 codegen bug PR79671: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D79671 >> >> Therefore I would like to add this now although >> the trunk is already at in stage 4. >> >> I propose to add a new type attribute always_alias that >> works like may_alias but unlike may_alias it should >> also make instances alias anything. It is also exposed >> in C/C++ as __attribute__((always_alias)). > > I have just two small comments, for review IMHO want agreement > between Jason and Richard on this. > > One thing is whether it is a good idea to keep this info in the IL > as an attribute, especially when you add it automatically in the > C++ FE. I see e.g. 25 spare bits in tree_type_common. Don't say we > need to waste them, but I'd say in C++ unsigned char arrays are fairly > common and thus not having to create the attribute for them each time > and look it up might be beneficial. > Yes, but it is not clear if it will be available in LTO, for instance we used to stream TYPE_ALIAS_SET =3D=3D 0 information to let frontends mark types that are opaque for TBAA. This however did not work as intended, because TYPE_ALIAS_SET =3D=3D 0 was regularly lost in type merging. But streaming an attribute works seamless, and is not lost in type merging AFAICT. > Also, wonder if you need to mark all types containing such arrays, > if you couldn't just set that flag in C++ on unsigned char/std::byte > arrays (and on anything with that attribute), have that imply alias set > 0 on it and then let the rest of alias machinery handle aggregate types > containing such fields. > Actually I set the flag only on C++ code with std::byte and struct/union with embedded unsigned char or std::byte arrays, but not on char arrays for instance, so I hope that it will not pessimize the codegen too much. The attribute does not propagate from normal std::byte to the enclosing structure. With LTO it is impossible to know which -std=3D option was used and all C and C++ code is merged together. So I was trying hard to fin a way how it can work without breaking LTO. Bernd.