https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127903
--- Comment #3 from Igor Shevlyakov <igor at tachyum dot com> ---
I can reproduce this, and as Andrew says the comparison mode is wrong.
The vector-comparison case in simplify_subreg calls
simplify_gen_relational (GET_CODE (op), outermode, innermode, ...)
and INNERMODE there is the mode of the comparison result (V4SI), not of
its operands (V4SF). simplify_const_relational_operation then decides
HONOR_NANS from V4SI and folds UNORDERED to 0. Passing VOIDmode, so the
mode is taken from the operands, fixes it.
With a loongarch64-linux-gnu cross compiler built from trunk (f16aa1c29ef),
-O3 -mlasx, on the testcase from comment 0:
before:
unord_cast3:
vrepli.b $vr0,0
vpickve2gr.du $r4,$vr0,0
vpickve2gr.du $r5,$vr0,1
jr $r1
after:
unord_cast3:
...
vfcmp.cun.s $vr0,$vr0,$vr1
...
vpickve2gr.du $r4,$vr0,0
vpickve2gr.du $r5,$vr0,1
jr $r1
and the bogus REG_EQUAL (const_vector:V4SF [0.0 x4]) note in fwprop1 is
gone. -O2 -mlsx, -O3 -mlsx and -O2 -flto -mlsx behave the same. This was
checked at the assembly level only (no LoongArch hardware run).
The patch also adds a simplify-rtx selftest; it fails without the fix in
a loongarch64 build and passes with it in loongarch64, aarch64 and
riscv64 builds.
