[PATCH] LoongArch: Optimize math barriers

[dengjianbo]

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.

  On 5/7/26 2:46 PM, Andreas Schwab wrote:
> On Mai 07 2026, Deng Jianbo wrote:
> 
>> The constraints 'frm' used in math_opt_barrier and math_force_eval cause
>> GCC choose fixed-point registers with lower costs in some cases, because
>> in LoongArch ira_reg_class_subunion[FP_REGS][GR_REGS] is initialized to
>> GR_REGS, extra move costs will be added when choosing FP_REGS. This
>> results in unnecessary instructions to move values between FP_REGS and
>> GR_REGS.
> 
> It looks like a bug in GCC (wrong cost calculations) if it generates
> unnecessary moves when it has more choices.
> 
>> Most of cases in GLIBC math barriers related macros are invoked with
>> floating-point type paramters, this patch removes "r" constraints,
>> allowing GCC to keep values in floating-point registers and avoid the
>> extra moves.
> 
> It does not *allow* that, it *forces* gcc to use an fp reg (or memory).
> What if the value is in a general reg in the first place, wouldn't that
> result in unnecessary moves?
>