From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2764 invoked by alias); 16 May 2018 16:30:43 -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 2277 invoked by uid 89); 16 May 2018 16:30:24 -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_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:1526487, H*f:sk:1526487, automagically, hesitate X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 May 2018 16:30:23 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F2B4A80D; Wed, 16 May 2018 09:30:08 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.221]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 65E853F24A; Wed, 16 May 2018 09:30:07 -0700 (PDT) Subject: Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP To: sellcey@cavium.com, Francesco Petrogalli Cc: 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> From: "Richard Earnshaw (lists)" Openpgp: preference=signencrypt Message-ID: Date: Wed, 16 May 2018 16:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1526487700.29509.6.camel@cavium.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-05/txt/msg00138.txt.bz2 On 16/05/18 17:21, Steve Ellcey wrote: > On Tue, 2018-05-15 at 18:29 +0000, Francesco Petrogalli wrote: > >> Hi Steve, >> >> I am happy to let you know that the Vector Function ABI for AArch64 >> is now public and available via the link at [1]. >> >> Don’t hesitate to contact me in case you have any questions. >> >> Kind regards, >> >> Francesco >> >> [1] https://developer.arm.com/products/software-development-tools/hpc >> /arm-compiler-for-hpc/vector-function-abi >> >>> >>> Steve Ellcey >>> sellcey@cavium.com > > Thanks for publishing this Francesco, it looks like the main issue for > GCC is that the Vector Function ABI has different caller saved / callee > saved register conventions than the standard ARM calling convention. > > If I understand things correctly, in the standard calling convention > the callee will only save the bottom 64 bits of V8-V15 and so the > caller needs to save those registers if it is using the top half.  In > the Vector calling convention the callee will save all 128 bits of > these registers (and possibly more registers) so the caller does not > have to save these registers at all, even if it is using all 128 bits > of them. > > It doesn't look like GCC has any existing mechanism for having different > sets of caller saved/callee saved registers depending on the function > attributes of the calling or called function. > > Changing what registers a callee function saves and restores shouldn't > be too difficult since that can be done when generating the prologue > and epilogue code but changing what registers a caller saves/restores > when doing the call seems trickier.  The macro > TARGET_HARD_REGNO_CALL_PART_CLOBBERED doesn't know anything about the > function being called.  It returns true/false depending on just the > register number and mode. > > Steve Ellcey > sellcey@cavium.com > Actually, we can. See, for example, the attribute((pcs)) for the ARM port. I think we could probably handle this automagically for the SVE vector calling convention in AArch64. R.