Messages in this thread | | | From | Huacai Chen <> | Date | Wed, 6 Jul 2022 10:35:15 +0800 | Subject | Re: [PATCH v2] LoongArch: Clean useless vcsr in loongarch_fpu. |
| |
Hi, all,
On Tue, Jul 5, 2022 at 6:01 PM Xi Ruoyao <xry111@xry111.site> wrote: > > On Tue, 2022-07-05 at 17:49 +0800, Xi Ruoyao wrote: > > On Tue, 2022-07-05 at 16:46 +0800, WANG Xuerui wrote: > > > > > Actually I'm still not very satisfied with the explanation; the code > > > must be written with *something* in mind, since GS464V/LA464 is the only > > > LoongArch implementation so far, it must have a VCSR to begin with. And > > > you can't magically melt the VCSR on the tens of thousands of > > > 3A5000/3C5000's already shipped, because the old-world kernel obviously > > > comes with LSX/LASX and it most likely utilizes the VCSR. In addition, > > > you didn't mention what will happen if LSX/LASX *is* enabled on this > > > new-world kernel, *and* fcsr16 is being accessed. > > > > > > I think maybe you just want to remove the mentions of VCSR since they > > > are dead code right now, as I don't believe it's gone in shipped > > > hardware, as explained above. Except if there's magically a way to > > > implement LSX/LASX without touching the said-to-have-disappeared VCSR, > > > which I don't know of, and can't know because the LSX/LASX ISA manual is > > > still not publicly accessible; so I don't feel comfortable approving > > > this patch. > > > > Let me make some bold guess here. In the MIPS-compatible 3A4000 we had > > "MSACSR" register. According to the MSA manual, only the 24-th bit of > > this register is used: > > > > "Some MSA floating point instructions might not handle subnormal input > > operands or compute tiny non-zero results. Such instructions may signal > > the Unimplemented Operation Exception and let the software emulation > > finalize the operation. If software emulation is not needed or desired, > > MSACSR FS bit could be set to replace every tiny non-zero result and > > subnormal input operand with zero of the same sign." > > > > And, it says: > > > > "Should the alternate exception handling attributes of the IEEE Standard > > for Floating-Point Arithmetic 754-2008, Section 8 be desired, the MSACSR > > FS bit should be zero, the Underflow Exception be enabled and a trap > > handler be provided to carry out the execution of the alternate > > exception handling attributes." > > > > We can see Loongson has been trying to make 3A processors more IEEE-754 > > compatible. For example, 3A4000 is the only non-R6 MIPS-compatible > > processor using IEEE-754-2008 NaN encoding. And LoongArch manual > > directly refers to IEEE-754-2008 manual in many places. So I guess this > > change means Loongson won't set this bit to 1 for 3A5000 at all, and any > > attempt by the user to set this bit could be considered undefined > > behavior (causing inconsistent behavior on 3A5000 as the kernel doesn't > > save/restore VCSR at context switch, and SIGILL on 3A6000 as the > > register is removed). > > P. S. I'm just playing an "intelligence game" writing the reply so maybe > I'm completely wrong. And, it does not indicate any position of me or > my affiliation about some "controversial topics". And, even if my guess > is correct, it's still better to add something like "the use of VCSR is > optional in LA464 and we've decided to remove it in future > architectures, so it's not supported to use it even on LA464" into the > commit message.
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. Am I right? Qi Hu?
If I'm right, Qi Hu, please tell us what control bits were in VCSR16, and where their replacements in FCSR are. Thanks.
Huacai
> -- > Xi Ruoyao <xry111@xry111.site> > School of Aerospace Science and Technology, Xidian University
| |