From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20235 invoked by alias); 29 May 2018 10:06:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 20222 invoked by uid 89); 29 May 2018 10:06:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*p:D*org, SET, *does*, USE X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 May 2018 10:06:47 +0000 Received: by mail-wm0-f50.google.com with SMTP id a67-v6so38693589wmf.3 for ; Tue, 29 May 2018 03:06:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=nHm02iaSLxYLEW3RxO+fZ2/9YieeLUDZkpL/DC9NYUE=; b=I5z+j90ixYFFgVzMFNdrWZ4wod4SfcOSjGz+YTxKW/m/yFqfROmXafpwP1gvfAe52C ip6NR0Z7VTOzA9LtEewWo5n9onh/CIfU5i7Fracsfcr8ikwKHdAH/5k6kx45XBOuNE6L CMuqVbKL5pDmOM9chA0uifgpiZrjdvjCtsrKcvgqGR69VmP81y1I/lSGZb52zpYcvl/d 2uDmazDMPFAxNnCbR7oMp9jWKcHMzd/mCkaBHJwTzKUzQE+3rZAIeIKNM9uGFam/9sVe QjPysXd1yef/pDLJq4zsPUCXMpu4LI2VLPrCmIMm6Ipy3Beh9rEBbXMTt960WJ3LqQV7 jmFg== X-Gm-Message-State: ALKqPwccD6H6vOIds7YZVbZxa9ejd6iDXT8SDFV4X1FxaHtKkrGxdzzP H+3kfy9ePVBqY9euOeTU5imYBA== X-Google-Smtp-Source: ADUXVKIwgKU/0XJTId4ERjVQrlNoXyBGf6oAgu+c+7sHenpEj2RmuYDVSBAO2GV4lxfe0arZkgvpLg== X-Received: by 2002:a1c:eec4:: with SMTP id j65-v6mr10147218wmi.150.1527588405905; Tue, 29 May 2018 03:06:45 -0700 (PDT) Received: from localhost ([217.140.96.141]) by smtp.gmail.com with ESMTPSA id g75-v6sm25605440wmd.15.2018.05.29.03.06.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 29 May 2018 03:06:45 -0700 (PDT) From: Richard Sandiford To: Jeff Law Mail-Followup-To: Jeff Law ,Steve Ellcey , Alan.Hayward@arm.com, "Richard Earnshaw \(lists\)" , Francesco Petrogalli , James Greenhalgh , "Sekhar\, Ashwin" , gcc , Marcus Shawcroft , nd , richard.sandiford@linaro.org Cc: Steve Ellcey , Alan.Hayward@arm.com, "Richard Earnshaw \(lists\)" , Francesco Petrogalli , James Greenhalgh , "Sekhar\, Ashwin" , gcc , Marcus Shawcroft , nd Subject: Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP References: <1518212868.14236.47.camel@cavium.com> <32617133-64DC-4F62-B7A0-A6B417C5B14E@arm.com> <1526487700.29509.6.camel@cavium.com> <1526491802.29509.19.camel@cavium.com> <87a7sznw5c.fsf@linaro.org> <1527184223.22014.13.camel@cavium.com> <87a7smbuej.fsf@linaro.org> Date: Tue, 29 May 2018 10:06:00 -0000 In-Reply-To: (Jeff Law's message of "Sun, 27 May 2018 09:59:31 -0600") Message-ID: <871sdubwv6.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-05/txt/msg00270.txt.bz2 Jeff Law writes: > Now that we're in stage1 I do want to revisit the CLOBBER_HIGH stuff. > When we left things I think we were trying to decide between > CLOBBER_HIGH and clobbering the appropriate subreg. The problem with > the latter is the dataflow we compute is inaccurate (overly pessimistic) > so that'd have to be fixed. The clobbered part of the register in this case is a high-part subreg, which is ill-formed for single registers. It would also be difficult to represent in terms of the mode, since there are no defined modes for what can be stored in the high part of an SVE register. For 128-bit SVE that mode would have zero bits. :-) I thought the alternative suggestion was instead to have: (set (reg:M X) (reg:M X)) when X is preserved in mode M but not in wider modes. But that seems like too much of a special case to me, both in terms of the source and the destination: - On the destination side, a SET normally provides something for later instructions to use, whereas here the effect is intended to be the opposite: the instruction has no effect at all on a value of mode M in X. As you say, this would pessimise df without specific handling. But I think all optimisations that look for the definition of a value would need to be taught to "look through" this set to find the real definition of (reg:M X) (or any value of a mode no larger than M in X). Very few passes use the df def-uses chains for this due its high cost. - On the source side, the instruction doesn't actually care what's in X, but nevertheless appears to use it. This means that most passes would need to be taught that a use of X on the rhs of a no-op SET is special and should usually be ignored. More fundamentally, it should be possible in RTL to express an instruction J that *does* read X in mode M and clobbers its high part. If we use the SET above to represent the clobber, and treat the rhs use as special, then presumably J would need two uses of X, one "dummy" one on the no-op SET and one "real" one on some other SET (or perhaps in a top-level USE). Having the number of uses determine this seems a bit awkward. IMO CLOBBER and SET have different semantics for good reason: CLOBBER represents an optimisation barrier for things that care about the value of a certain rtx object, while SET represents a productive effect or side-effect. The effect we want here is the same as a normal clobber, except that the clobber is mode-dependent. Thanks, Richard