On Wed, 2024-01-03 at 16:24 +0800, chenglulu wrote:
> LGTM!
>
> Thanks!
Pushed r14-6890.
FWIW sometimes tree optimizer still fails to emit .reduc_f{max,min} or
it emits them sub-optimally. I've commented in PR112457 but maybe I
should've created a new ticket...
> 在 2024/1/1 上午3:15, Xi Ruoyao 写
LGTM!
Thanks!
在 2024/1/1 上午3:15, Xi Ruoyao 写道:
We already had smin/smax RTL pattern using vfmin/vfmax instructions.
But for smin/smax, it's unspecified what will happen if either operand
contains any NaN operands. So we would not vectorize the loop with
-fno-finite-math-only (the default for a
We already had smin/smax RTL pattern using vfmin/vfmax instructions.
But for smin/smax, it's unspecified what will happen if either operand
contains any NaN operands. So we would not vectorize the loop with
-fno-finite-math-only (the default for all optimization levels expect
-Ofast).
But, LoongA
Looks good to me.
在 2022/8/16 下午4:08, Xi Ruoyao 写道:
A simple optimization. Ok for trunk?
-- >8 --
We already had smin/smax RTL pattern using fmin/fmax instruction. But
for smin/smax, it's unspecified what will happen if either operand is
NaN. So we would generate calls to libc fmin/fmax fu
A simple optimization. Ok for trunk?
-- >8 --
We already had smin/smax RTL pattern using fmin/fmax instruction. But
for smin/smax, it's unspecified what will happen if either operand is
NaN. So we would generate calls to libc fmin/fmax functions with
-fno-finite-math-only (the default for all
