This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc 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>, linux-arm-kernel at lists dot infradead dot org
- Cc: Christoffer Dall <christoffer dot dall at linaro dot org>, Ard Biesheuvel <ard dot biesheuvel at linaro dot org>, Marc Zyngier <Marc dot Zyngier at arm dot com>, Alan Hayward <alan dot hayward at arm dot com>, libc-alpha at sourceware dot org, gdb at sourceware dot org, Torvald Riegel <triegel at redhat dot com>
- Date: Wed, 30 Nov 2016 11:08:50 +0100
- Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
- Authentication-results: sourceware.org; auth=none
- References: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
On 11/25/2016 08:38 PM, Dave Martin wrote:
The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which
adds extra SIMD functionality and supports much larger vectors.
This series implements core Linux support for SVE.
Recipents not copied on the whole series can find the rest of the
patches in the linux-arm-kernel archives [2].
The first 5 patches "arm64: signal: ..." factor out the allocation and
placement of state information in the signal frame. The first three
are prerequisites for the SVE support patches.
Patches 04-05 implement expansion of the signal frame, and may remain
controversial due to ABI break issues:
* Discussion is needed on how userspace should detect/negotiate signal
frame size in order for this expansion mechanism to be workable.
I'm leaning towards a simple increase in the glibc headers (despite the
ABI risk), plus a personality flag to disable really wide vector
registers in case this causes problems with old binaries.
A more elaborate mechanism will likely introduce more bugs than it makes
existing applications working, due to its complexity.
The remaining patches implement initial SVE support for Linux, with the
following limitations:
* No KVM/virtualisation support for guests.
* No independent SVE vector length configuration per thread. This is
planned, but will follow as a separate add-on series.
Per-thread register widths will likely make coroutine switching
(setcontext) and C++ resumable functions/executors quite challenging.
Can you detail your plans in this area?
Thanks,
Florian