From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108087 invoked by alias); 5 Dec 2016 15:05:03 -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 108037 invoked by uid 89); 5 Dec 2016 15:05:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=38AM, 38am, respond X-Spam-User: qpsmtpd, 2 recipients 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; Mon, 05 Dec 2016 15:05:00 +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 15B6F15A1; Mon, 5 Dec 2016 07:04:59 -0800 (PST) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7DEC23F4F6; Mon, 5 Dec 2016 07:04:57 -0800 (PST) Date: Mon, 05 Dec 2016 15:05:00 -0000 From: Dave Martin To: Florian Weimer Cc: libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Yao Qi , Christoffer Dall , Alan Hayward , Torvald Riegel , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support Message-ID: <20161205150452.GT1574@e103592.cambridge.arm.com> 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> <0293f7d3-b3d3-1a68-5b99-75db195eb796@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0293f7d3-b3d3-1a68-5b99-75db195eb796@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-12/txt/msg00011.txt.bz2 On Mon, Dec 05, 2016 at 11:44:38AM +0100, Florian Weimer wrote: > 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? I'll respond to these via Szabolcs' reply. > >>>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? No -- the idea is to be directly compatible with the existing PCS. > If not, we should be able to use the existing dynamic linker trampoline. Yes, I believe so. Cheers ---Dave