From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90773 invoked by alias); 30 Nov 2016 14:10:19 -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 90736 invoked by uid 89); 30 Nov 2016 14:10:18 -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=policy 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; Wed, 30 Nov 2016 14:10:17 +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 274E616; Wed, 30 Nov 2016 06:10:16 -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 5018E3F318; Wed, 30 Nov 2016 06:10:14 -0800 (PST) Date: Wed, 30 Nov 2016 14:10:00 -0000 From: Dave Martin To: Szabolcs Nagy Cc: Florian Weimer , Yao Qi , Torvald Riegel , libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Christoffer Dall , Alan Hayward , nd@arm.com, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support Message-ID: <20161130141011.GM1574@e103592.cambridge.arm.com> References: <20161130120654.GJ1574@e103592.cambridge.arm.com> <583EC488.9010906@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <583EC488.9010906@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-11/txt/msg00071.txt.bz2 On Wed, Nov 30, 2016 at 12:22:32PM +0000, Szabolcs Nagy wrote: > On 30/11/16 12:06, Dave Martin wrote: > > For setcontext/setjmp, we don't save/restore any SVE state due to the > > caller-save status of SVE, and I would not consider it necessary to > > save/restore VL itself because of the no-change-on-the-fly policy for > > this. > > the problem is not changing VL within a thread, > but that setcontext can resume a context of a > different thread which had different VL and there > might be SVE regs spilled on the stack according > to that. > > (i consider this usage undefined, but at least > the gccgo runtime does this) Understood -- which is part of the reason for the argument that although the kernel may permit different threads to have different VLs, whether this actually works usefully also depends on your userspace runtime environment. This again leads me to the conclusion that the request to create threads with different VLs within a single process should be explicit, in order to avoid accidents. Cheers ---Dave