Re: [PATCH v2] LoongArch: Clean useless vcsr in loongarch_fpu.

From: WANG Xuerui
Date: Wed Jul 06 2022 - 23:05:37 EST


On 2022/7/7 09:29, Qi Hu wrote:

On 2022/7/7 04:49, Jiaxun Yang wrote:

在2022年7月6日七月 上午5:00,Qi Hu写道:
On 2022/7/6 10:51, Xi Ruoyao wrote:
On Wed, 2022-07-06 at 10:35 +0800, Huacai Chen wrote:

Maybe Xuerui and Ruoyao have some misunderstanding. LSX/LASX will
surely be upstream, this has nothing to do with cleanup VCSR16.
Because FP/LSX/LASX share the same control bits in FCSR now.
My guess:

Almost all behavior of vector unit is controlled by FCSR (for example,
the rounding of both FPU and vector unit should be controlled by FCSR
altogether), except one bit similar to the bit 24 of MSACSR ("flush to
zero") is in VCSR [^1].  And "flush to zero" is not really useful so it
will be removed in 3A6000, and we'll not use it for 3A5000.
Actually, flush to zero has been removed in 3A5000.
[^1]: A more bold guess: the hardware engineers could have just said
"let's wire this register called MSACSR in GS464V as FCSR16/VCSR in
LA464, maybe it will be useful and who knows?"  But now in practice it's
not useful.

Am I correct?
The hardware(LA464) has removed the vcsr("has but not use" is
incorrect), and here are some details:

- For all FP operations, including LSX/LASX, they are controlled by
fcsr0/1/2/3.

- For LSX/LASX other operations, they are *not* controlled by any other
CSR now. And fcsr16 to fcsr31 are reserved to control these operations
(now they are *undefined*).
Sorry but what do you meant by “these” here?
"These operations" means "LSX/LASX other operations", except its floating-point operations.

This is getting hard to follow. Assuming the expression "LSX/LASX other operations" is Chinglish (it's certainly not proper English), I think you mean "the non-FP operations belonging to LSX/LASX" here right?

And it's strange, that these ops do exist in LSX/LASX, hence also present in 3A5000, but the control bits are undefined. How come this is even possible?

If it means LSX/LASX, are you trying to say that future chip’s LSX/LASX won’t be
compatible with present 3A5000? As your said fcsr16 and fcsr31 are undefined
for now.

Thanks
-

"not compatible" is incorrect. If future chips add new features to define and use these registers, some bits in CPUCFG should be set, like CPUID in X86.

And at that time, if the applications do not use these new features(like some old apps), they can run at *default* state which is the same as current 3A5000.

So, "reserved" is just to prepare for adding something, not "incompatible".

To be frank, at this point I think you're trying to hide something. (This is not your fault, blame someone else of course because they told you the fact.) In the old-world kernel the VCSR a.k.a. FCSR16 is certainly being saved/restored, and there's apparently no harm in doing so. And if the contents are indeed "undefined", why are the code there in the first place? Certainly the bits *are* meaningful, only that for some reason you aren't revealing the semantics and pretending that they are "undefined" and probably "do nothing externally observable" if accessed in the first place.

Then, either

(1) I am wrong and being hyper-aggressive here (and if it turns out to be the case, I'd immediately apologize for that), and the VCSR is indeed only meaningful for some early development steppings of 3A5000, and does nothing on the 3A5000 we all have now;

or, (2) the VCSR is still relevant for the "other" applicable LSX/LASX ops on 3A5000, but this patch is taking the VCSR out thus rendering such ops unreliable/incorrect in case they depend on the additional state.

Either way, the new-world kernel is handling LSX/LASX differently from the old-world, and I fear this would create unnecessary churn both in kernel and downstream projects already carrying LSX/LASX assembly, in case they actually used said ops. I can't rule out such possibility because at this time all LSX/LASX assembly was written by Loongson people with access to the manuals, and tested on old-world systems, so they might not be aware that some non-FP ops are going to magically change behavior on new-world systems because VCSR is suddenly not being saved/restored.

(Actually, people outside of Loongson might never know if (2) is the case, because the insns dependent on VCSR could be simply deleted from manuals, so they "don't exist" for outsiders, and "compatibility" of course doesn't suffer.)


Thanks.

- Flush to zero(MSACSR.FS) is removed and not supported.

- If you use "movfcsr2gr" to read the fcsr16, the value is *UNDEFINED*.