From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77234 invoked by alias); 5 Aug 2016 13:30:32 -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 77130 invoked by uid 89); 5 Aug 2016 13:30:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=@samp, ifclear, @ifclear, samp X-HELO: SNT004-OMC3S48.hotmail.com Received: from snt004-omc3s48.hotmail.com (HELO SNT004-OMC3S48.hotmail.com) (65.54.51.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Fri, 05 Aug 2016 13:30:27 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com ([65.55.90.137]) by SNT004-OMC3S48.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 5 Aug 2016 06:30:25 -0700 Received: from DB5EUR01FT030.eop-EUR01.prod.protection.outlook.com (10.152.4.54) by DB5EUR01HT171.eop-EUR01.prod.protection.outlook.com (10.152.5.43) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.567.7; Fri, 5 Aug 2016 13:30:23 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.4.52) by DB5EUR01FT030.mail.protection.outlook.com (10.152.4.254) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.567.7 via Frontend Transport; Fri, 5 Aug 2016 13:30:22 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) with mapi id 15.01.0549.023; Fri, 5 Aug 2016 13:30:21 +0000 From: Bernd Edlinger To: Jeff Law , Jakub Jelinek CC: "gcc-patches@gcc.gnu.org" , Vladimir Makarov , Richard Biener , Marc Glisse Subject: Re: [PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155) Date: Fri, 05 Aug 2016 13:30:00 -0000 Message-ID: References: <20160606180128.GC7387@tucnak.redhat.com> <20160606180845.GD7387@tucnak.redhat.com> <20160606194047.GF7387@tucnak.redhat.com> <74b7fd4b-e060-c3e8-16bb-9f529a7dc4b2@redhat.com> <20160609164304.GT7387@tucnak.redhat.com> <20160609164545.GU7387@tucnak.redhat.com> <32ad9b3d-a0cf-3e8d-4887-fea39ff05d0e@redhat.com> In-Reply-To: <32ad9b3d-a0cf-3e8d-4887-fea39ff05d0e@redhat.com> authentication-results: spf=softfail (sender IP is 10.152.4.52) smtp.mailfrom=hotmail.de; redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.de discourages use of 10.152.4.52 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.4.52;IPV:NLI;CTRY:;EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:DB5EUR01HT171;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-microsoft-exchange-diagnostics: 1;DB5EUR01HT171;6:K5N/92dlX8DYrJT9QiUUnxWY8VUyTTJDFuVO3GD43cFjzy7as7TnbcEHY5F1SNPhDcjTfhAo58fkYpMtKmy5rDYcR7mCx/1iK8H+fcrlmCuteZ0MH7xr9WnI7Sw5EphxfFTFyX9VperJjHLqSRDXoupXhh+XfGU7+CyY79cDgyL0ObasVq7XFdcYWdoCcI+zrACrg7YNSG81/HZxZL0SYua++P9JVdU2QBavh9RW2kRVlhGY4mea6GnCniad2cLrARLlhZKAutWwFAG3SJjyti6x9QEOCkC2/HmJq9hq0pU8LNPW6CTpc0d30pTjhWsS;5:x8W0vZnEzp2LkLKP1YO54mPaDl5EvJu2txrcY7EhPSCKqUqf2THNc9X8Wbi+qD/VQDmEpZ13H6qNNRh1S09YF6K/WTau9l9rwUhB5VbgSaYqgOBmgVX9gIilFZ4KqjjEQc1oHVzmO7bW7sUhr+tx0g==;24:rWUhokHZHZr6rE7HsSmot+O7VjLB7Wfh4LY27y11BeiuEE0VVktJpEzgH95jejjjVm/inyS+CEd4vYKxOkvbDY5ZFk22lOWXKeNExEiv/Ac=;7:3fY7zzVa20kWjtLfsrv8OiGm4Pln4Q0jpAnUtXUaxl7DPOgA0PC8eMSOtjB7TNZllps6YsOr44xt0bYb5mWPTQts7551II+1XFDCTNG0XRUWMPQ6VisGmjQipIRxUOe9uXYqHA2bbChYZLvzveFZFOOvdvLLuEDSAbQDGawUQDjT1Z3y4GPwXRmFJiOJo4/+t208dn4V9x9C7vj509tRUPhDRsKHLTqQJIzumFU4hVIn7C7lheU+LoiXrql8FCsB x-ms-office365-filtering-correlation-id: e6896bcd-8334-4197-831f-08d3bd34a5cf x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(1601124038)(1601125047);SRVR:DB5EUR01HT171; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:DB5EUR01HT171;BCL:0;PCL:0;RULEID:;SRVR:DB5EUR01HT171; x-forefront-prvs: 0025434D2D spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <56A8BAC3AC8D434C823C21DEBED21938@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2016 13:30:21.5528 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT171 X-SW-Source: 2016-08/txt/msg00455.txt.bz2 On 08/04/16 22:27, Jeff Law wrote: > On 07/21/2016 10:29 AM, Bernd Edlinger wrote: >>>> But I think we have a use case where "X" means really more possible >>>> registers (i.e. includes ss2, mmx etc.) than "g" (only general >>>> registers). Otherwise, in the test cases of pr59155 we would not >>>> have any benefit for using "+X" instead of "+g" or "+r". >>>> >>>> Does that sound reasonable? >>> If it's the case that the real benefit of +X is that it's allowing more >>> registers, then that argues that the backend ought to be providing >>> another (larger) register class. >>> >> >> X allows more different registers than r, and it is already documented. >> In the cases where it is already used, the patch should not break >> anything. I would not understand, why we should forbid the use of X and >> waste another letter of the alphabet for a slightly modified version >> of X. > Doing so essentially allows us to deprecate "X" to used by target > patterns only -- where what's acceptable is limited by the operand > predicates. Those limits ultimately protect the rest of the routines > from having to handle arbitrary RTL. > > Meanwhile asms can use the new letter to say "I'll take any register of > any class". Which is, AFAICT, what's desired here. > > jeff Yes. To be useful it should be a target independent letter. While "g" implies a general register of class GENERAL_REGS "X" implies any register of class ALL_REGS. I have looked for uses of "X" and actually found some of them in glibc: ./sysdeps/powerpc/powerpc64/dl-machine.h: /* GCC 4.9+ eliminates the branch as dead code, force the odp set dependency. */ asm ("" : "=3Dr" (value) : "0" (&opd), "X" (opd)); ./sysdeps/mach/hurd/i386/init-first.c: *--newsp =3D *((int *) __builtin_frame_address (0) + 1); /* GCC 4.4.6 also wants us to force loading *NEWSP already here. */ asm volatile ("# %0" : : "X" (*newsp)); and same file: usercode =3D *((int *) __builtin_frame_address (0) + 1); /* GCC 4.4.6 also wants us to force loading USERCODE already=20 here. */ asm volatile ("# %0" : : "X" (usercode)); So in is mostly used for obfuscating the data flow. The documentation of "g" at md.texi says @cindex @samp{g} in constraint @item @samp{g} Any register, memory or immediate integer operand is allowed, except for registers that are not general registers. and "X" says: @ifset INTERNALS Any operand whatsoever is allowed, even if it does not satisfy @code{general_operand}. This is normally used in the constraint of a @code{match_scratch} when certain alternatives will not actually require a scratch register. @end ifset @ifclear INTERNALS Any operand whatsoever is allowed. @end ifclear The part ifset INTERNALS describes the rules for target patterns, while the ifclear INTERNALS part describes the rules for asms. This is exactly what we want. Not saying "except for registers that are not general registers" is a hint that there are more registers in the ALL_REGS class. We could make it more explicit by adding "Including registers that are not general registers". And "whatsoever" means anything you can write down at the source code level IMO. So I think restricting "X" in asms to this definition while keeping the current meaning of "X" in target patterns is consistent with the current documentation and compatible to the current uses of the "X" constraint elsewhere. Bernd.