Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <16c9ccaa5e5a2ffd39272cff6f66e487c659b571.camel@xry111.site>
Subject: Re: [PATCH v2] LoongArch: Clean useless vcsr in loongarch_fpu.
From:   Xi Ruoyao <xry111@xry111.site>
To:     WANG Xuerui <kernel@xen0n.name>, Qi Hu <huqi@loongson.cn>,
        Huacai Chen <chenhuacai@kernel.org>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc:     loongarch@lists.linux.dev, linux-kernel@vger.kernel.org
Date:   Tue, 05 Jul 2022 18:00:52 +0800
In-Reply-To: <22a1ba993e298ce12a374decefebeca484240883.camel@xry111.site>
References: <20220704153612.314112-1-huqi@loongson.cn>
         <4273e104-8392-6a06-5d18-a1933978d8c3@xen0n.name>
         <22a1ba993e298ce12a374decefebeca484240883.camel@xry111.site>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.3 
MIME-Version: 1.0
Precedence: bulk

On Tue, 2022-07-05 at 17:49 +0800, Xi Ruoyao wrote:
> On Tue, 2022-07-05 at 16:46 +0800, WANG Xuerui wrote:
>=20
> > Actually I'm still not very satisfied with the explanation; the code
> > must be written with *something* in mind, since GS464V/LA464 is the onl=
y=20
> > LoongArch implementation so far, it must have a VCSR to begin with. And=
=20
> > you can't magically melt the VCSR on the tens of thousands of=20
> > 3A5000/3C5000's already shipped, because the old-world kernel obviously=
=20
> > 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.
> >=20
> > I think maybe you just want to remove the mentions of VCSR since they=
=20
> > are dead code right now, as I don't believe it's gone in shipped=20
> > hardware, as explained above. Except if there's magically a way to=20
> > 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 i=
s=20
> > still not publicly accessible; so I don't feel comfortable approving
> > this patch.
>=20
> Let me make some bold guess here.=C2=A0 In the MIPS-compatible 3A4000 we =
had
> "MSACSR" register.=C2=A0 According to the MSA manual, only the 24-th bit =
of
> this register is used:
>=20
> "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."
>=20
> And, it says:
>=20
> "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."
>=20
> We can see Loongson has been trying to make 3A processors more IEEE-754
> compatible.=C2=A0 For example, 3A4000 is the only non-R6 MIPS-compatible
> processor using IEEE-754-2008 NaN encoding.=C2=A0 And LoongArch manual
> directly refers to IEEE-754-2008 manual in many places.=C2=A0 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.
--=20
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University