[PATCH v7 1/2] arm64/sve: Split TIF_SVE into separate execute and register state flags
broonie at kernel.org
Wed Feb 10 12:14:42 EST 2021
On Wed, Feb 10, 2021 at 03:42:51PM +0000, Dave Martin wrote:
> On Wed, Feb 10, 2021 at 02:54:52PM +0000, Mark Brown wrote:
> > Oh, *that's* what that's all about. I spent quite a bit of time trying
> > to figure out why we were sometimes using vq_minus_1 but never managed
> > to get to the bottom of it - it's an awkward name and there's nothing in
> > the code that explains the logic behind when we use it so it was really
> > confusing. We can do the rename but I'm not sure it's achieving the
> > goal of comprehensibility.
> Ah, I see. The reason for the difference is that the vector length is
> encoded in ZCR_ELx.LEN as the vector length in quadwords ("vq" -- see
> Documentation/arm64/sve.rst) minus one. It seemed poor practice to do
> the conversion in asm where the compiler can't see or optimise it, plus
> I didn't want the possibility of passing meaningless values at that
> level. So the caller has to validate the vector length with
> sve_vl_valid() where deemed necessary, and then convert explicitly.
Yeah, it's relatively clear to get to the fact that it's due to the
ZCR_ELx.LEN - what was not at all clear was what the rule for choosing
between the two representations was, my instinct would've been to hide
the different representation, something like a static inline wrapper for
the assembly function would still let the compiler see what's going on.
> Either way, calling this "vl" is breaking a useful convention that's
> followed throughout the rest of the kernel, so I'd prefer we call it
> something else -- but within reason, I don't mind what name is used.
That's the convention in the arm64 FP code or something else?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: not available
More information about the linux-arm-kernel