From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39979 invoked by alias); 11 Jun 2018 23:06:57 -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 39967 invoked by uid 89); 11 Jun 2018 23:06:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=SET, Application, inaccurate, H*f:sk:1518212 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Jun 2018 23:06:55 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0F8E130C10EA; Mon, 11 Jun 2018 23:06:54 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-10.rdu2.redhat.com [10.10.112.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 07F5417B6C; Mon, 11 Jun 2018 23:06:50 +0000 (UTC) Subject: Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP To: Alan Hayward , Richard Sandiford Cc: Steve Ellcey , Richard Earnshaw , Francesco Petrogalli , James Greenhalgh , "Sekhar, Ashwin" , gcc , Marcus Shawcroft , nd 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> <871sdubwv6.fsf@linaro.org> <8F853649-0510-4397-B255-C64FA42C671A@arm.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Tue, 12 Jun 2018 03:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <8F853649-0510-4397-B255-C64FA42C671A@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00144.txt.bz2 On 05/31/2018 04:39 AM, Alan Hayward wrote: > (Missed this thread initially due to incorrect email address) Sorry. Good to hear your're still interested in figuring this out. > >> On 29 May 2018, at 11:05, Richard Sandiford wrote: >> >> 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. > > Yes, I want to get back to looking at this again, however I’ve been busy > elsewhere. Similarly. > >> >> 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: > > Agreed. When I looked at doing it that way back in Jan, my conclusion was > that if we did it that way we end up with more or less the same code but > instead of: > > if (GET_CODE (setter) == CLOBBER_HIGH > && reg_is_clobbered_by_clobber_high(REGNO(dest), GET_MODE (rsp->last_set_value)) > > Now becomes something like: > > if (GET_CODE (setter) == SET > && REG_P (dest) && HARD_REGISTER_P (dest) && REG_P (src) && REGNO(dst) == REGNO(src) > && reg_is_clobbered_by_self_set(REGNO(dest), GET_MODE (rsp->last_set_value)) > > Ok, some of that code can go into a macro, but it feel much clearer to > explicitly check for CLOBBER_HIGH rather then applying some special semantics > to a specific SET case. Then let's return to the CLOBBER_HIGH approach. The hope was that most of the places where you had to introduce CLOBBER_HIGH would "just work" with the self-set approach. If that's not the case, then there's really nothing to be gained with self-set. I suggest you get the patch updated for the trunk and repost now that we're in broad agreement that self-set is a rathole. jeff