From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124160 invoked by alias); 8 Nov 2018 13:27:21 -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 124132 invoked by uid 89); 8 Nov 2018 13:27:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:981, H*RU:209.85.215.193, Hx-spam-relays-external:209.85.215.193, HX-HELO:sk:mail-pg X-HELO: mail-pg1-f193.google.com Received: from mail-pg1-f193.google.com (HELO mail-pg1-f193.google.com) (209.85.215.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Nov 2018 13:27:20 +0000 Received: by mail-pg1-f193.google.com with SMTP id i4-v6so8857248pgq.9 for ; Thu, 08 Nov 2018 05:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=UVHJ1pztP1+M38EtbGcqO5ACcGCkQK9FvFITHrlBmeU=; b=j4q5mXr1DjE/0FplH30aqqp5q4teTZ4ygVmhF1Vpw8RnJRLDakieuuSurCjeoq+lGO mxp8ehDkfhOoVsgvGJ6vyHHsrL8DpJ7bGh6Aa0qgPk/UFBEUr7u42eA9QIqdo4gccJ7f UVTEKxFZMy3L8HVuKYjCG0PQ6HYVsdWfqVsVi/BLavqLIzLpk2ffHVSjEVtUxFdM1cdx gQXpRHpXkC5nrrB0f+B9Xg+7FMcAgRriPUUR8BxVeWJURkxdwnNR5Y4GlCHUYJTZQJ3c MRqjKAEZj4M5DHByOPKtpbyPx/2xF3ELKn3BdPyAwqww+vb4/Sn2nmNLL2UEoVVIgF3z ZtYQ== Return-Path: Received: from bubble.grove.modra.org ([58.175.241.133]) by smtp.gmail.com with ESMTPSA id r81-v6sm6825742pfa.110.2018.11.08.05.27.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Nov 2018 05:27:17 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id CF84680575; Thu, 8 Nov 2018 23:57:13 +1030 (ACDT) Date: Thu, 08 Nov 2018 13:27:00 -0000 From: Alan Modra To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 3/6] [RS6000] Replace TLSmode with P, and correct tls call mems Message-ID: <20181108132713.GW29482@bubble.grove.modra.org> References: <20181107053326.GM29482@bubble.grove.modra.org> <20181107053826.GP29482@bubble.grove.modra.org> <20181108011128.GO5994@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181108011128.GO5994@gate.crashing.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00564.txt.bz2 On Wed, Nov 07, 2018 at 07:11:28PM -0600, Segher Boessenkool wrote: > On Wed, Nov 07, 2018 at 04:08:26PM +1030, Alan Modra wrote: > > There is really no need to define a TLSmode mode iterator that is > > identical (since !TARGET_64BIT == TARGET_32BIT) to the much used P > > mode iterator. > > Nice :-) > > > It's nonsense to think we might ever want to support > > 32-bit TLS on 64-bit or vice versa! The patch also fixes a minor > > error in the call mems. All other direct calls use (call (mem:SI ..)). > > You can also replace with , with > , and l with . Also, was "TLSmode:" > needed anywhere? I don't see any other iterator used in those patterns. OK, done. TLSmode: was used in the tls insn pattern names and in the output templates that now use ptrload. P: does just as well. -- Alan Modra Australia Development Lab, IBM