From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13920 invoked by alias); 16 May 2018 21:11:33 -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 13905 invoked by uid 89); 16 May 2018 21:11:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=hs, Hx-spam-relays-external:209.85.128.195, H*RU:209.85.128.195, PCS X-HELO: mail-wr0-f195.google.com Received: from mail-wr0-f195.google.com (HELO mail-wr0-f195.google.com) (209.85.128.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 May 2018 21:11:31 +0000 Received: by mail-wr0-f195.google.com with SMTP id o4-v6so3437017wrm.0 for ; Wed, 16 May 2018 14:11:30 -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 :content-transfer-encoding; bh=naRCJrpso5ytXTvyJtwPqKLT3UN2EWh5q6QXRwiU2/Y=; b=N3hLq+EsAyI9UjE5Xr0puhl4AzUBJkTtYJ/Zf3I0ua0zPzboFeUdD+8p5QdheCSwl+ I+2wuv49yqHdXa8b19v8H+D47FjyHqpiOXfRTnVEPHa3bw4VbGeYYG6K0BjivYc6Y0F/ GtY99gBKYD9JPP3mbBmqGSOv+6fyL0PScvxvFglchPb54G89mLdZI0LzedhzcBBsZFFz jPTmLz7bFW/xaWYZ2aKH+cijvlox0vAM4sN8xkxPUQBpvYoR48GXoMD40AQwMM0LqbBa GFT65w2HRP2IuZ8u+Y5uc+QSEESYfd6W/xjnJk5fovUBZ+Vac/YiRNolTluArKLqsgmX D7Vg== X-Gm-Message-State: ALKqPwcsHEhnH527HdadTvubTCEiBztoOolLaXRWeOF/Y2X+c/2V1DBa Iwth6dg1OeLIWwOZIOsAMMnivA== X-Google-Smtp-Source: AB8JxZoi4CrbetqGfLxzmd1BTTO3UH8hThzgS5wLI05+DgnrKmsT/2sTsFJmmau22iS6AY+SL2SGGA== X-Received: by 2002:adf:a58a:: with SMTP id g10-v6mr2161496wrc.233.1526505088487; Wed, 16 May 2018 14:11:28 -0700 (PDT) Received: from localhost (116.58.7.51.dyn.plus.net. [51.7.58.116]) by smtp.gmail.com with ESMTPSA id x70-v6sm5159285wma.9.2018.05.16.14.11.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 May 2018 14:11:27 -0700 (PDT) From: Richard Sandiford To: Steve Ellcey Mail-Followup-To: Steve Ellcey ,"Richard Earnshaw \(lists\)" , Francesco Petrogalli , James Greenhalgh , "Sekhar\, Ashwin" , gcc , Marcus Shawcroft , nd , richard.sandiford@linaro.org Cc: "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> Date: Wed, 16 May 2018 21:11:00 -0000 In-Reply-To: <1526491802.29509.19.camel@cavium.com> (Steve Ellcey's message of "Wed, 16 May 2018 10:30:02 -0700") Message-ID: <87a7sznw5c.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-05/txt/msg00144.txt.bz2 Steve Ellcey writes: > On Wed, 2018-05-16 at 17:30 +0100, Richard Earnshaw (lists) wrote: >> On 16/05/18 17:21, Steve Ellcey wrote: >> >=C2=A0 >> > It doesn't look like GCC has any existing mechanism for having differe= nt >> > sets of caller saved/callee saved registers depending on the function >> > attributes of the calling or called function. >> >=20 >> > 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.=C2=A0=C2=A0The macro >> > TARGET_HARD_REGNO_CALL_PART_CLOBBERED doesn't know anything about the >> > function being called.=C2=A0=C2=A0It returns true/false depending on j= ust the >> > register number and mode. >> >=20 >> > Steve Ellcey >> > sellcey@cavium.com >> >=20 >>=20 >> Actually, we can.=C2=A0=C2=A0See, for example, the attribute((pcs)) for = the ARM >> port.=C2=A0=C2=A0I think we could probably handle this automagically for= the SVE >> vector calling convention in AArch64. >>=20 >> R. > > Interesting, it looks like one could use aarch64_emit_call to emit > extra use_reg / clobber_reg instructions but in this case we want to > tell the caller that some registers are not being clobbered by the > callee. =C2=A0The ARM port does not > define=C2=A0TARGET_HARD_REGNO_CALL_PART_CLOBBERED and that seemed like one > of the most problamatic issues with Aarch64. =C2=A0Maybe we would have to > undefine this for aarch64 and use explicit clobbers to say what > floating point registers / vector registers are clobbered for each > call? =C2=A0I wonder how that would affect register allocation. TARGET_HARD_REGNO_CALL_PART_CLOBBERED is the only current way of saying that an rtl instruction preserves the low part of a register but clobbers the high part. We would need something like Alan H's CLOBBER_HIGH patches to do it using explicit clobbers. Another approach would be to piggy-back on the -fipa-ra infrastructure and record that vector PCS functions only clobber Q0-Q7. If -fipa-ra knows that a function doesn't clobber Q8-Q15 then that should override TARGET_HARD_REGNO_CALL_PART_CLOBBERED. (I'm not sure whether it does in practice, but it should :-) And if it doesn't that's a bug that's worth fixing for its own sake.) Thanks, Richard