From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48590 invoked by alias); 28 Nov 2018 01:07:51 -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 48580 invoked by uid 89); 28 Nov 2018 01:07:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=expense, sprintf, H*RU:209.85.214.196, Hx-spam-relays-external:209.85.214.196 X-HELO: mail-pl1-f196.google.com Received: from mail-pl1-f196.google.com (HELO mail-pl1-f196.google.com) (209.85.214.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Nov 2018 01:07:49 +0000 Received: by mail-pl1-f196.google.com with SMTP id p8so6204973plo.2 for ; Tue, 27 Nov 2018 17:07:49 -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=cQMQHe6hpq6yNdPzVd3SW0FEWyopxB16WxVXnRiLXz4=; b=VjH6kZBN+YkRQU7K938SYPM2cZgXY2qFl2ymfsUz7COoPwwr2CQSKjdkI8XwFi1dGK pxOzj8Lx8WkaaYTJEtA7kXEKSJPCelGUg4KkvBEgrjxg/AGaCa0G2jfrsgNfC2MPZ7Cs 3AR/eLPW85OQi6QGTnCa5wLY8/bdjrwnpLYQ4MKIQwad/GaPuD6ZFmKiFybSP/ui2wJ2 Iv+HSiwXDaf1cMviu0+/yy5rosn8CMvn5AzU2AUPVTP0GBgA7zpQZp1xeqHsFZcfvhTQ qJgp28I/mwdSzT7erfpwYvKcX3VakXGT4qtNa5cWIJWabNoOzuGkCYty2LjrCeDETndw Y7Mg== Return-Path: Received: from bubble.grove.modra.org ([58.175.241.133]) by smtp.gmail.com with ESMTPSA id n73sm6848555pfj.148.2018.11.27.17.07.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Nov 2018 17:07:46 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 9397880494; Wed, 28 Nov 2018 11:37:42 +1030 (ACDT) Date: Wed, 28 Nov 2018 01:07:00 -0000 From: Alan Modra To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 5/6] [RS6000] Use standard call patterns for __tls_get_addr calls Message-ID: <20181128010742.GD13363@bubble.grove.modra.org> References: <20181107053326.GM29482@bubble.grove.modra.org> <20181107053751.GO29482@bubble.grove.modra.org> <2c5b2155-b4ce-b95a-8848-121c4398fb67@linux.ibm.com> <20181113001424.GD29784@bubble.grove.modra.org> <20181113111407.GP23873@gate.crashing.org> <20181113125243.GU29784@bubble.grove.modra.org> <20181127162929.GU23873@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181127162929.GU23873@gate.crashing.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg02259.txt.bz2 On Tue, Nov 27, 2018 at 10:29:29AM -0600, Segher Boessenkool wrote: > Hi! Thanks for the review! > > +(define_insn "*tls_gdld_aix" > > + [(match_parallel 3 "" > > A match_parallel without predicate... Does this work?! Yes. In fact, rs6000/predicates.md any_parallel_operand is useless except as documentation. The only thing it checks is that its operand is a parallel, but that has already been checked. > Does this not > accidentally pick up the wrong things? No. The purpose of the predicate is to match anything beyond the vector of expressions. So tls_gdld_aix* matches insns that look like: (set (match_operand:P 0 "gpc_reg_operand" "=b") (call (mem:SI (match_operand:P 1)) (match_operand:P 2 "unspec_tls"))) (match_dup 2) ... This is sufficiently different from other calls, by virtue of the "(match_dup 2)". Incidentally, I think tls_gdld_aix and tls_gdld_sysv could be merged at the expense of complicating the length attribute expression. > Do you think we should to deprecate -mtls-markers in GCC 9? Support for the TLS marker relocs was added to binutils in 2009 (git commit 727fc41e077), so yes, the option is not likely to be useful nowadays. > Please test with -mtls-markers, too, if you can, and test on AIX. Presumably you mean -mno-tls-markers. -mtls-markers is the default. > Looks fine. Thank you for the cleanup! Okay for trunk, but please do the > extra testing. Huh, local testing of -mno-tls-markers showed a lack of a TARGET_TLS_MARKERS check in rs6000_call_template_1. Likely this would blow up on AIX. I'll test with the following delta. diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 56ca117a0a0..5f4fcee3b33 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -8622,7 +8622,7 @@ edit_tls_call_insn (rtx arg) } /* Passes the tls arg value for global dynamic and local dynamic - emit_library_call_value in rs6000_legitimize_Tls_address to + emit_library_call_value in rs6000_legitimize_tls_address to rs6000_call_aix and rs6000_call_sysv. This is used to emit the marker relocs put on __tls_get_addr calls. */ static rtx global_tlsarg; @@ -21429,7 +21429,7 @@ rs6000_call_template_1 (rtx *operands, unsigned int funop, bool sibcall) char arg[12]; arg[0] = 0; - if (GET_CODE (operands[funop + 1]) == UNSPEC) + if (TARGET_TLS_MARKERS && GET_CODE (operands[funop + 1]) == UNSPEC) { if (XINT (operands[funop + 1], 1) == UNSPEC_TLSGD) sprintf (arg, "(%%%u@tlsgd)", funop + 1); -- Alan Modra Australia Development Lab, IBM