From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91181 invoked by alias); 20 Jul 2016 20:04:54 -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 91163 invoked by uid 89); 20 Jul 2016 20:04:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=reg-tested, boot-strapped, Vladimir, Hx-languages-length:2158 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 20 Jul 2016 20:04:53 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C460381F03; Wed, 20 Jul 2016 20:04:51 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6KK4p6T026129; Wed, 20 Jul 2016 16:04:51 -0400 Subject: Re: [PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155) To: Bernd Edlinger , Jakub Jelinek 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> Cc: "gcc-patches@gcc.gnu.org" , Vladimir Makarov , Richard Biener From: Jeff Law Message-ID: Date: Wed, 20 Jul 2016 20:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg01317.txt.bz2 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. jeff