From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8468 invoked by alias); 5 Dec 2016 10:44:45 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 8430 invoked by uid 89); 5 Dec 2016 10:44:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=restored, scalable, Scalable, Extension X-Spam-User: qpsmtpd, 2 recipients 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, 05 Dec 2016 10:44:43 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DDAC62F912F; Mon, 5 Dec 2016 10:44:41 +0000 (UTC) Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB5AicdP027274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2016 05:44:40 -0500 Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support To: Dave Martin References: <20161130120654.GJ1574@e103592.cambridge.arm.com> <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com> <20161130135631.GK1574@e103592.cambridge.arm.com> <20161201103048.GO1574@e103592.cambridge.arm.com> Cc: libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Yao Qi , linux-arm-kernel@lists.infradead.org, Alan Hayward , Torvald Riegel , Christoffer Dall From: Florian Weimer Message-ID: <0293f7d3-b3d3-1a68-5b99-75db195eb796@redhat.com> Date: Mon, 05 Dec 2016 10:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161201103048.GO1574@e103592.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00009.txt.bz2 On 12/01/2016 11:30 AM, Dave Martin wrote: >> The VL value is implicitly thread-local data, and the encoded state may have >> an implicit dependency on it, although it does not contain vector registers >> as such. > > This doesn't sound like an absolute requirement to me. > > If we presume that the SVE registers never need to get saved or > restored, what stops the context data format being VL-independent? I'm concerned the suspended computation has code which has been selected to fit a particular VL value. > If the save/restore logic doesn't touch SVE, which would its > implementation be VL-dependent? Because it has been optimized for a certain vector length? >>> Because the SVE procedure call standard determines that the SVE >>> registers are caller-save, >> >> By the way, how is this implemented? Some of them overlap existing >> callee-saved registers. > > Basically, all the *new* state is caller-save. > > The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view > Zn[bits 127:0] is callee-save for all n = 8..15. Are the extension parts of registers v8 to v15 used for argument passing? If not, we should be able to use the existing dynamic linker trampoline. Thanks, Florian