Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

[Xi Ruoyao <xry111@xry111.site>]

On Thu, 2023-11-23 at 17:12 +0800, chenglulu wrote:
> 
> 在 2023/11/23 下午5:02, Xi Ruoyao 写道:
> > On Thu, 2023-11-23 at 16:13 +0800, chenglulu wrote:
> > > The fix_truncv4sfv4si2 template is indeed called when debugging with
> > > gdb.
> > > 
> > > So I think we can use define_expand here.
> > The problem is cases where we want to combine an rint call with float-
> > to-int conversion:
> > 
> > float x[4];
> > int y[4];
> > 
> > void test()
> > {
> > 	for (int i = 0; i < 4; i++)
> > 		y[i] = __builtin_rintf(x[i]);
> > }
> > 
> > With define_expand we get "vfrint + vftintrz", but with define_insn we
> > get a single "vftint".
> > 
> > Arguably the generic code should try to handle this (PR86609), but it's
> > "not sure if that's a good idea in general" (comment 1 in the PR) so we
> > can do this in a target-specific way.
> > 
> I tried to use Ofast to compile, and found that a vftint was generated, 
> and at.006t.gimple appeared.
> 
> If O2 was compiled, __builtin_rintf would be generated, but Ofast would 
> generate __builtin_irintf

Indeed...  It seems the FE will only generate __builtin_irintf when -
fno-math-errno -funsafe-math-optimizations.

But I cannot see why this is necessary (at least for us): the rintf
function does not set errno at all, and to me using vftint.w.s here is
safe: if the rounded result can be represented as a 32-bit int,
obviously there is no issue;  otherwise, per C23 section F.4 we should
raise FE_INVALID and produce unspecified result.  It seems our ftint.w.s
instruction has the required semantics.

+Uros and Joseph for some comment about the expected behavior of
(int)rintf(x).

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University