This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
- From: Florian Weimer <fweimer at redhat dot com>
- To: Dave Martin <Dave dot Martin at arm dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, libc-alpha at sourceware dot org, Ard Biesheuvel <ard dot biesheuvel at linaro dot org>, Marc Zyngier <Marc dot Zyngier at arm dot com>, gdb at sourceware dot org, Christoffer Dall <christoffer dot dall at linaro dot org>, Alan Hayward <alan dot hayward at arm dot com>, Torvald Riegel <triegel at redhat dot com>, linux-arm-kernel at lists dot infradead dot org
- Date: Thu, 1 Dec 2016 10:21:03 +0100
- Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
- Authentication-results: sourceware.org; auth=none
- References: <20161130120654.GJ1574@e103592.cambridge.arm.com> <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com> <20161130135631.GK1574@e103592.cambridge.arm.com>
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