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>
- Cc: 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, Yao Qi <qiyaoltc at gmail dot com>, linux-arm-kernel at lists dot infradead dot org, Alan Hayward <alan dot hayward at arm dot com>, Torvald Riegel <triegel at redhat dot com>, Christoffer Dall <christoffer dot dall at linaro dot org>
- Date: Mon, 5 Dec 2016 11:44:38 +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> <dbcd545f-1358-6a80-5a9f-3e4a3c93189a@redhat.com> <20161201103048.GO1574@e103592.cambridge.arm.com>
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?
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?
If not, we should be able to use the existing dynamic linker trampoline.
Thanks,
Florian