From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79360 invoked by alias); 1 Dec 2016 09:21:10 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 79339 invoked by uid 89); 1 Dec 2016 09:21:09 -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=suspension X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com 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> Cc: Yao Qi , libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Christoffer Dall , Alan Hayward , Torvald Riegel , linux-arm-kernel@lists.infradead.org From: Florian Weimer Message-ID: Date: Thu, 01 Dec 2016 09:21: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: <20161130135631.GK1574@e103592.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-12/txt/msg00008.txt.bz2 On 11/30/2016 02:56 PM, Dave Martin wrote: > If we do have distinct "set process VL" and "set thread VL" interfaces, > then my view is that the former should fail if there are already > multiple threads, rather than just setting the VL of a single thread or > (worse) asynchronously changing the VL of threads other than the > caller... Yes, looks feasible to me. >>> I'm not familiar with resumable functions/executors -- are these in >>> the C++ standards yet (not that that would cause me to be familiar >>> with them... ;) Any implementation of coroutines (i.e., >>> cooperative switching) is likely to fall under the "setcontext" >>> argument above. >> >> There are different ways to implement coroutines. Stack switching (like >> setcontext) is obviously impacted by non-uniform register sizes. But even >> the most conservative variant, rather similar to switch-based emulation you >> sometimes see in C coroutine implementations, might have trouble restoring >> the state if it just cannot restore the saved state due to register size >> reductions. > > Which is not a problem if the variably-sized state is not part of the > switched context? 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. > 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. > they are not live at any external function > boundary -- so in cooperative switching it is useless to save/restore > this state unless the coroutine framework is defined to have a special > procedure call standard. It can use the standard calling convention, but it may have selected a particular implementation based on the VL value before suspension. Florian