From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120717 invoked by alias); 7 Jun 2016 17:58: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 120706 invoked by uid 89); 7 Jun 2016 17:58:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:15.01.0506.016, H*r:15.01.0506.016, H*RU:15.01.0506.016, H*Ad:D*inria.fr X-HELO: BLU004-OMC4S30.hotmail.com Received: from blu004-omc4s30.hotmail.com (HELO BLU004-OMC4S30.hotmail.com) (65.55.111.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Tue, 07 Jun 2016 17:58:18 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com ([65.55.111.137]) by BLU004-OMC4S30.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 7 Jun 2016 10:58:16 -0700 Received: from DB5EUR01FT064.eop-EUR01.prod.protection.outlook.com (10.152.4.54) by DB5EUR01HT202.eop-EUR01.prod.protection.outlook.com (10.152.5.117) with Microsoft SMTP Server (TLS) id 15.1.497.8; Tue, 7 Jun 2016 17:58:12 +0000 Received: from AM4PR07MB1571.eurprd07.prod.outlook.com (10.152.4.53) by DB5EUR01FT064.mail.protection.outlook.com (10.152.5.83) with Microsoft SMTP Server (TLS) id 15.1.511.7 via Frontend Transport; Tue, 7 Jun 2016 17:58:12 +0000 Received: from AM4PR07MB1571.eurprd07.prod.outlook.com ([10.165.249.15]) by AM4PR07MB1571.eurprd07.prod.outlook.com ([10.165.249.15]) with mapi id 15.01.0506.016; Tue, 7 Jun 2016 17:58:12 +0000 From: Bernd Edlinger To: Jakub Jelinek , Jeff Law CC: Vladimir Makarov , "gcc-patches@gcc.gnu.org" , Richard Biener , Marc Glisse Subject: Re: [PING] [PATCH] Fix asm X constraint (PR inline-asm/59155) Date: Tue, 07 Jun 2016 17:58:00 -0000 Message-ID: References: <5755AD05.4010608@redhat.com> <20160606180128.GC7387@tucnak.redhat.com> <20160606180845.GD7387@tucnak.redhat.com> In-Reply-To: <20160606180845.GD7387@tucnak.redhat.com> authentication-results: spf=softfail (sender IP is 25.152.4.53) 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 25.152.4.53 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:25.152.4.53;IPV:NLI;CTRY:GB;EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:DB5EUR01HT202;H:AM4PR07MB1571.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-office365-filtering-correlation-id: 094abd83-0f30-455f-b826-08d38efd49ed x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(1601124038)(5061506196)(5061507196)(1603103041)(1601125047);SRVR:DB5EUR01HT202; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:DB5EUR01HT202;BCL:0;PCL:0;RULEID:;SRVR:DB5EUR01HT202; x-forefront-prvs: 09669DB681 Content-Type: text/plain; charset="Windows-1252" Content-ID: <99056C9FA6CB1D49921923995CF20829@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 17:58:11.9589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT202 X-SW-Source: 2016-06/txt/msg00507.txt.bz2 On 06/06/16 20:08, Jakub Jelinek wrote: > On Mon, Jun 06, 2016 at 12:04:04PM -0600, Jeff Law wrote: >> On 06/06/2016 12:01 PM, Jakub Jelinek wrote: >>> On Mon, Jun 06, 2016 at 11:54:04AM -0600, Jeff Law wrote: >>>>> As for recog.c, I can not approve this as I am not a maintainer of it. >>>>> I only can say that the code looks questionable to me. >>>> I think the question on the recog part is a matter of how we choose to >>>> interpret what the "X" constraint means. >>>> >>>> Does it literally mean accept anything, or accept some subset expressi= ons? >>>> >>>> I tend to think the former, which means that things like >>>> reg_overlap_mentioned_p or its callers have to be bullet-proofed. AFACT this is not the only place where overly complex RTL trees can cause an ICE. >>> >>> I think it is a bad idea to accept really anything, even for debug insn= s, >>> which initially accepted arbitrarily large RTL expressions (and still a= ccept >>> stuff like subregs otherwise considered invalid etc.) we found it is hi= ghly >>> undesirable, as it is not very good idea for the compile time complexity >>> etc., so now we are trying to limit the complexity of the expressions t= here >>> by splitting up more complex expressions into smaller ones using tempor= aries. >>> So, even accept anything should always be accept anything reasonable, >>> because most of the RTL passes don't really expect arbitrarily deep >>> expressions, or expressions where the same reg can appear thousands of = times >>> etc. >> The problem is how do you define this subset of expressions you're going= to >> accept and those which you are going to reject. >> >> I first pondered accepting RTL leaf nodes (reg, subreg, constants) and >> rejecting everything else. But I couldn't convince myself that some port >> might reasonably expect (plus (x) (y)) to match the "X" constraint. > > It is always going to be arbitrary. > Perhaps RTL leaf nodes (if including MEM, then perhaps with valid address > only), and unary/binary/ternary RTL expressions with RTL leaf node operan= ds? > Or union of what is accepted by any other constraint? > Or "g" plus any constants? Yes. That is what I think too, "X" is probably not used often in practice, but if it is allowed, it should at least not result in an ICE. "X" should allow to feed "whatsoever" valid C expressions to the asm input, and using the %-expression in the assembler string should not cause an ICE. And "X" really means different "whatsoever" things in asm statements and in .md files, even md.texi has different text for internally used "X" constraint and assembler "X" constraint, so that should be OK. According to md.texi "g" should already mean: @item @samp{g} Any register, memory or immediate integer operand is allowed, except for registers that are not general registers. Which is the same as general_operand(op, VOIDmode). And in other words, that should be everything that is in "r", "m" and "i" constraints. However if I compare commond.md ... (define_constraint "i" "Matches a general integer constant." (and (match_test "CONSTANT_P (op)") (match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)"))) ... against recog.c, general_operand seems to allow less i.e. checks targetm.legitimate_constant_p additionally. So that is something I don't really understand, I mean if a constant is not a "legitimate" constant by the target's definition, why should it be safe to use in later in targetm.asm_out.print_operand? Bernd.