Hi Segher,
在 2022/11/18 20:18, Segher Boessenkool 写道:
> I don't think we should pretend we have any conditional jumps the
> machine does not actually have, in cbranchcc4. When would this ever be
> useful? cror;beq can be quite expensive, compared to the code it would
> replace anyway.
>
> If something generates those here (which then ICEs later), that is
> wrong, fix *that*? Is it ifcvt doing it?
"*cbranch_2insn" is a valid insn for rs6000. So it generates such insn
at expand pass. The "prepare_cmp_insn" called by ifcvt just wants to verify
that the following comparison rtx is valid.
(unlt (reg:CCFP 156)
(const_int 0 [0]))
It should be valid as it's extracted from an existing insn. It hits ICE only
when the comparison rtx can't pass the predicate check of "cbranchcc4". So
"cbranchcc4" should include "extra_insn_branch_comparison_operator".
Then, ifcvt tries to call emit_conditional_move_1 to generates a condition
move for FP mode. It definitely fails as there is no conditional move insn for
FP mode in rs6000. The behavior of ifcvt is correct. It tries to do conversion
but fails. It won't hit ICEs after cbranchcc4 is correctly defined.
Actually, "*cbranch_2insn" has the same logical as float "*cbranch" in ifcvt.
Both of them get a final false return from "rs6000_emit_int_cmove" as rs6000
doesn't have conditional move for FP mode.
So I think "cbranchcc4" should include "extra_insn_branch_comparison_operator"
as "*cbranch_2insn" is a valid insn. Just let ifcvt decide a conditional
move is valid or not.
Thanks
Gui Haochen
