From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21124 invoked by alias); 21 Jul 2016 16:30:31 -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 21107 invoked by uid 89); 21 Jul 2016 16:30:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=letter X-HELO: COL004-OMC4S2.hotmail.com Received: from col004-omc4s2.hotmail.com (HELO COL004-OMC4S2.hotmail.com) (65.55.34.204) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Thu, 21 Jul 2016 16:30:29 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com ([65.55.34.201]) by COL004-OMC4S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 21 Jul 2016 09:30:19 -0700 Received: from DB5EUR01FT023.eop-EUR01.prod.protection.outlook.com (10.152.4.54) by DB5EUR01HT036.eop-EUR01.prod.protection.outlook.com (10.152.5.48) with Microsoft SMTP Server (TLS) id 15.1.539.16; Thu, 21 Jul 2016 16:29:58 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.4.54) by DB5EUR01FT023.mail.protection.outlook.com (10.152.4.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5 via Frontend Transport; Thu, 21 Jul 2016 16:29:58 +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.0544.014; Thu, 21 Jul 2016 16:29:57 +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: Thu, 21 Jul 2016 16:30:00 -0000 Message-ID: References: <5755AD05.4010608@redhat.com> <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> In-Reply-To: authentication-results: spf=softfail (sender IP is 10.152.4.54) 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.54 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.4.54;IPV:NLI;CTRY:;EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:DB5EUR01HT036;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-microsoft-exchange-diagnostics: 1;DB5EUR01HT036;7:viuELaGhUVYU7N/MrpskFoun6Q6Fpib8xFXugSppCX316kgdMVJmSD2kBTE9VjCwqD4ZCroqLQk5Ru98H69v6RxkIEYURjDfb05Lqg4DvhfjZ7o6ImVl7UPndiW8ZuACS1kgAy5kIxQ0l0N1nr6m7eDVlXsfQz6dA+Ktinbd4qbGAKd6TU+XOQIpz9BQAlb8RlyYcFLFeNW6WscxYijFvSPseC4rghFdFSJT0aTbcT+c5w0gzMYBZWVnlXfJeGEM x-ms-office365-filtering-correlation-id: 1aa95f5a-d9bf-4bbc-05c1-08d3b184407c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(1601124038)(5061506196)(5061507196)(1603103041)(1601125047);SRVR:DB5EUR01HT036; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:DB5EUR01HT036;BCL:0;PCL:0;RULEID:;SRVR:DB5EUR01HT036; x-forefront-prvs: 0010D93EFE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <5965C6EB6EE37243A792CF007C0801C6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 16:29:57.3458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT036 X-SW-Source: 2016-07/txt/msg01397.txt.bz2 On 07/20/16 22:04, Jeff Law wrote: > On 06/22/2016 02:48 PM, Bernd Edlinger wrote: >> On 06/22/16 21:51, Jeff Law wrote: >>> On 06/19/2016 07:25 AM, Bernd Edlinger wrote: >>>> Hi, >>>> >>>> ping... >>>> >>>> As this discussion did not make any progress, I just attached >>>> the latest version of my patch with the the changes that >>>> Vladimir proposed. >>>> >>>> Boot-strapped and reg-tested again on x86_64-linux-gnu. >>>> Is it OK for the trunk? >>> Well, I don't think we've got any kind of consensus on whether or not >>> this is reasonable or not. >>> >>> The fundamental issue is that "X" is supposed to accept anything, >>> literally anything. That implies it's really the downstream users of >>> those operands that are broken. >>> >> >> Hmm... >> >> I think it must be pretty easy to write something in a .md file with the >> X constraint that ends up in an ICE, right? > Probably not terribly hard. > >> >> But in an .md file we have much more control on what happens. >> That's why I did not propose to change the meaning of "X" in .md files. > We have control over RTL generation, operand predicates and the like. > And those are how we control things like combine. > >> >> And we only have problems with asm statements that use "X" constraints. > But I'd disagree. I think we could easily have problems with "X" > constraints in the MD file. But the most common uses of "X" probably > don't try to refer to that operand in the output string and use good > predicates. > > And that's one of the key differences here. In an MD file the operand > predicate has to pass -- that's not the case in an ASM. The operand > predicate allows the backend to prevent all kinds of things from showing > up. > >> >> 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. Bernd.