Add more experts in CC.
on 2022/11/23 10:54, HAO CHEN GUI wrote:
> Hi,
> I want to enable "have_cbranchcc4" on rs6000. But not all combinations of
> comparison codes and sub CC modes are benefited to generate cbranchcc4 insns
> on rs6000. There is an predicate for operand0 of cbranchcc4 to bypass
> some combinations. It gets assertion failure in prepare_cmp_insn. I think
> we shouldn't suppose that all comparison codes and sub CC modes are supported
> and throw an assertion failure in prepare_cmp_insn. It might check the
> predicate and go to fail if the predicate can't be satisfied. This patch
> changes the behavior of those codes.
>
> Bootstrapped and tested on powerpc64-linux BE/LE and x86 with no
> regressions.
> Is this okay for trunk? Any recommendations? Thanks a lot.
>
>
> ChangeLog
> 2022-11-23 Haochen Gui <guih...@linux.ibm.com>
>
> gcc/
> * optabs.cc (prepare_cmp_insn): Go to fail other than assert it when
> predicate check of "cbranchcc4" operand[0] fails.
>
> patch.diff
> diff --git a/gcc/optabs.cc b/gcc/optabs.cc
> index 165f8d1fa22..3ec8f6b17ba 100644
> --- a/gcc/optabs.cc
> +++ b/gcc/optabs.cc
> @@ -4484,8 +4484,9 @@ prepare_cmp_insn (rtx x, rtx y, enum rtx_code
> comparison, rtx size,
> {
> enum insn_code icode = optab_handler (cbranch_optab, CCmode);
> test = gen_rtx_fmt_ee (comparison, VOIDmode, x, y);
> - gcc_assert (icode != CODE_FOR_nothing
> - && insn_operand_matches (icode, 0, test));
> + gcc_assert (icode != CODE_FOR_nothing);
> + if (!insn_operand_matches (icode, 0, test))
> + goto fail;
IMHO, this change looks to accord with the other code in prepare_cmp_insn, which
allows the preparation to fail with NULL_RTX ptest. Its caller can make its own
decision (ICE due to unexpected, or try other ways) when ptest is null.
If this direction is sensible, maybe we can make it goto fail too if the icode
==
CODE_FOR_nothing, since we already try to relax the restriction.
BR,
Kewen
> *ptest = test;
> return;
> }
