Re: [PATCH] LoongArch: Optimize math barriers

[dengjianbo <dengjianbo@loongson.cn>]

  On 5/8/26 5:47 PM, dengjianbo wrote:
> 
> 
>   On 5/8/26 5:29 PM, Xi Ruoyao wrote:
>> On Thu, 2026-05-07 at 17:30 +0800, dengjianbo wrote:
>>> Yes, unnecessary moves can occur if the value is already in a general
>>> reg. For example, when invoking math_opt_barrier with fixed-point
>>> parameters. However, in glibc, these two macros are invoked with
>>> floating-point parameters, and I didn’t find the unnecessary moves
>>> being generated. For other architectures, aarch64 and s390 also do
>>> not include the 'r' constraint.
>>>
>>> For gcc part, to my understanding, when 'fr' is present, GCC selects the
>>> union of FP_REGS and GR_REGS as the destination register class, which is
>>> initialized to GR_REGS. Then compute the cost of choosing different
>>> register classes, choosing GR_REGS incurs no extra cost, while choosing
>>> FP_REGS adds an extra move cost. I am not sure if it's a strategy here.
>>
>> Where does this issue manifest (i.e. in which glibc source file)?  I'll
>> try to reduce a test case from that.  To me this seems a compiler bug
>> too.
>>>
>>
> One example is the xflow function, compiler generates the unnecessary 
> moves for this function, the source file is sysdeps/ieee754/dbl-64 
> /math_err.c．

Just a gentle ping on the patch, maybe the below test case can be used
to reproduce this problem.

#define math_opt_barrier(x)                 \
   ({ __typeof (x) __x = (x); __asm ("" : "+frm" (__x)); __x; })

double
test (double x)
{
   x = math_opt_barrier (x);
   return x;
}