From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52759 invoked by alias); 20 Jan 2019 13:38:44 -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 52743 invoked by uid 89); 20 Jan 2019 13:38:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Google-Smtp-Source:ALg8bN4, kill, RS6000, CLOBBER X-HELO: mail-pf1-f181.google.com Received: from mail-pf1-f181.google.com (HELO mail-pf1-f181.google.com) (209.85.210.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 20 Jan 2019 13:38:41 +0000 Received: by mail-pf1-f181.google.com with SMTP id z9so8879997pfi.2 for ; Sun, 20 Jan 2019 05:38:41 -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=p7uaC2euFk19ZuedcckCP5hOq1ghaurNLn/feEbbERY=; b=DpoFw1RHtE+dWc2iOP1GgjD3PJziHhqto6LIECh0Lb4tt5ypOBa2W62HvxY24WUEhj lPVnHGmD+WfwNuM5NNIUWCUwAGULldnYyn0HZCfCleT4mV8HeUFsZkw2lACf37t7v4J8 +bi6BYr9AFgikKDRXVw37pWMzfzAKFobYDardrLTzKJWVeEuKvvtMKUH1R7aopSdaIWT pB7KMzI0CZzg2Fhon6KgDWxwv/+lIv0cF1daVfSwdjAQJanuWhJZFQicLeQhbS58KsGA 6LP8szeoaSt15QEYIWakzEefpjIs5gi5XxLEyH/g3+VT0zDhLIOPQM9V4EcvHvGLeyGv gnzQ== Return-Path: Received: from bubble.grove.modra.org ([58.175.241.133]) by smtp.gmail.com with ESMTPSA id l11sm13229962pff.65.2019.01.20.05.38.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 20 Jan 2019 05:38:37 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id D10C680531; Mon, 21 Jan 2019 00:08:33 +1030 (ACDT) Date: Sun, 20 Jan 2019 13:38:00 -0000 From: Alan Modra To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org Subject: Re: [RS6000] PR88614, output_operand: invalid %z value Message-ID: <20190120133833.GF29797@bubble.grove.modra.org> References: <20190106225918.GG3170@bubble.grove.modra.org> <20190118220213.GT14180@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190118220213.GT14180@gate.crashing.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg01146.txt.bz2 On Fri, Jan 18, 2019 at 04:02:14PM -0600, Segher Boessenkool wrote: > Hi Alan, > > On Mon, Jan 07, 2019 at 09:29:18AM +1030, Alan Modra wrote: > > The direct cause of this PR is the fact that tls_gdld_nomark didn't > > handle indirect calls. Adding the missing support revealed that most > > indirect calls were being optimised back to direct calls anyway, due > > to tls_gdld_nomark not checking any of the parallel elements except > > the first (plus the extra element that distinguishes this call from > > normal calls). Just checking the number of elements is enough to > > separate the indirect calls from direct for ABI_ELFv2 and ABI_AIX, > > while checking for the LONG_CALL bit in the cookie works for ABI_V4. > > Direct calls being substituted for indirect calls is not the only > > unwanted substitution. See the tls_nomark_call comment. I also saw a > > _GLOBAL_OFFSET_TABLE_ symbol_ref being substituted for the GOT reg, > > hence the unspec_tls change. > > > Bootstrap and regression testing on powerpc64le-linux and > > powerpc64-linux in progress. Note that the patch requires > > https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00252.html or the > > earlier version for the attribute support. > > (Did you commit that yet?) Yes, the prerequisite patches have been committed. > > +;; Verify that elements of the tls_gdld_nomark call insn parallel past the > > +;; second element (added to distinguish this call from normal calls) match > > +;; the normal contours of a call insn. This is necessary to prevent > > +;; substitutions we don't want, for example, an indirect call being > > +;; optimised to a direct call, or (set (reg:r2) (unspec [] UNSPEC_TOCSLOT)) > > +;; being cleverly optimised to (set (reg:r2) (reg:r2)) because gcc > > +;; "knows" that r2 hasn't changed from a previous call. > > +(define_predicate "tls_nomark_call" > > + (match_code "parallel") > > +{ > > + int n = XVECLEN (op, 0); > > + rtvec v = XVEC (op, 0); > > + rtx set = RTVEC_ELT (v, 0); > > + if (GET_CODE (set) != SET) > > + return 0; > > + rtx call = XEXP (set, 1); > > + if (GET_CODE (call) != CALL) > > + return 0; > > + rtx mem = XEXP (call, 0); > > + if (GET_CODE (mem) != MEM) > > + return 0; > > + rtx addr = XEXP (mem, 0); > > + if (GET_CODE (addr) == SYMBOL_REF) > > + { > > + if (DEFAULT_ABI == ABI_ELFv2 || DEFAULT_ABI == ABI_AIX) > > + return (n == 3 && GET_CODE (RTVEC_ELT (v, 2)) == CLOBBER > > + && REG_P (XEXP (RTVEC_ELT (v, 2), 0)) > > + && REGNO (XEXP (RTVEC_ELT (v, 2), 0)) == LR_REGNO); > > + else if (DEFAULT_ABI == ABI_V4) > > + return (n >= 4 && n <= 5 && GET_CODE (RTVEC_ELT (v, 2)) == USE > > + && CONST_INT_P (XEXP (RTVEC_ELT (v, 2), 0)) > > + && (INTVAL (XEXP (RTVEC_ELT (v, 2), 0)) & CALL_LONG) == 0 > > + && (n == 4 > > + || (GET_CODE (RTVEC_ELT (v, 3)) == USE > > + && REG_P (XEXP (RTVEC_ELT (v, 3), 0)))) > > + && GET_CODE (RTVEC_ELT (v, n - 1)) == CLOBBER > > + && REG_P (XEXP (RTVEC_ELT (v, n - 1), 0)) > > + && REGNO (XEXP (RTVEC_ELT (v, n - 1), 0)) == LR_REGNO); > > + else > > + gcc_unreachable (); > > + } > > + else if (indirect_call_operand (addr, mode)) > > + { > > + if (DEFAULT_ABI == ABI_ELFv2) > > + return (n == 4 && GET_CODE (RTVEC_ELT (v, 2)) == SET > > + && REG_P (XEXP (RTVEC_ELT (v, 2), 0)) > > + && REGNO (XEXP (RTVEC_ELT (v, 2), 0)) == TOC_REGNUM > > + && GET_CODE (XEXP (RTVEC_ELT (v, 2), 1)) == UNSPEC > > + && XINT (XEXP (RTVEC_ELT (v, 2), 1), 1) == UNSPEC_TOCSLOT > > + && XVECLEN (XEXP (RTVEC_ELT (v, 2), 1), 0) == 1 > > + && CONST_INT_P (XVECEXP (XEXP (RTVEC_ELT (v, 2), 1), 0, 0)) > > + && GET_CODE (RTVEC_ELT (v, 3)) == CLOBBER > > + && REG_P (XEXP (RTVEC_ELT (v, 3), 0)) > > + && REGNO (XEXP (RTVEC_ELT (v, 3), 0)) == LR_REGNO); > > + else if (DEFAULT_ABI == ABI_AIX) > > + return (n == 5 && GET_CODE (RTVEC_ELT (v, 2)) == USE > > + && GET_CODE (XEXP (RTVEC_ELT (v, 2), 0)) == MEM > > + && GET_CODE (RTVEC_ELT (v, 3)) == SET > > + && REG_P (XEXP (RTVEC_ELT (v, 3), 0)) > > + && REGNO (XEXP (RTVEC_ELT (v, 3), 0)) == TOC_REGNUM > > + && GET_CODE (XEXP (RTVEC_ELT (v, 3), 1)) == UNSPEC > > + && XINT (XEXP (RTVEC_ELT (v, 3), 1), 1) == UNSPEC_TOCSLOT > > + && XVECLEN (XEXP (RTVEC_ELT (v, 3), 1), 0) == 1 > > + && CONST_INT_P (XVECEXP (XEXP (RTVEC_ELT (v, 3), 1), 0, 0)) > > + && GET_CODE (RTVEC_ELT (v, 4)) == CLOBBER > > + && REG_P (XEXP (RTVEC_ELT (v, 4), 0)) > > + && REGNO (XEXP (RTVEC_ELT (v, 4), 0)) == LR_REGNO); > > + else if (DEFAULT_ABI == ABI_V4) > > + return (n == 4 && GET_CODE (RTVEC_ELT (v, 2)) == USE > > + && CONST_INT_P (XEXP (RTVEC_ELT (v, 2), 0)) > > + && GET_CODE (RTVEC_ELT (v, 3)) == CLOBBER > > + && REG_P (XEXP (RTVEC_ELT (v, 3), 0)) > > + && REGNO (XEXP (RTVEC_ELT (v, 3), 0)) == LR_REGNO); > > + else > > + gcc_unreachable (); > > + } > > + else > > + return 0; > > +}) > > I find things like this almost impossible to read (and to verify for > correctness). Maybe you can factor it a bit more? Does it need to be a > predicate at all, or can you handle it by having various patterns? Hmm, if I invent a couple of new unspecs, UNSPEC_TLSGD_NOMARK and UNSPEC_TLSLD_NOMARK, using them in place of UNSPEC_TLSGD and UNSPEC_TLSLD when !TARGET_TLS_MARKERS then that should be enough to tell when we have a -mno-tls-markers __tls_get_addr call. So I guess I could kill off edit_tls_call_insn and tls_gdld_nomark. The call_value_local and call_value_indirect insns would then need to detect the special call and emit the arg setup insns. -- Alan Modra Australia Development Lab, IBM