public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: HAO CHEN GUI <guihaoc@linux.ibm.com>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	"Kewen.Lin" <linkw@linux.ibm.com>,
	Peter Bergner <bergner@linux.ibm.com>
Subject: Re: [PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000
Date: Fri, 18 Nov 2022 14:35:30 +0800	[thread overview]
Message-ID: <b3d5f0f8-b16c-6845-ca15-687207e625b5@linux.ibm.com> (raw)
In-Reply-To: <CAGWvnym54qRGozi_6_y2Tm3YkSc7AHVPiMQ7nyuGe9B9+=nbAQ@mail.gmail.com>

Hi David,

在 2022/11/17 21:24, David Edelsohn 写道:
> This is better, but the pattern should be near and after the existing cbranch<mode>4 patterns earlier in the file, not the *cbranch pattern.  It doesn't match the comment.
Sure, I will put it after existing "cbranch<mode>4" patterns.

> 
> Why are you using zero_constant predicate instead of matching (const_int 0) for operand 2?
The "const_int 0" is an operand other than a predicate. We need a predicate here.

> 
> Why does this need the new all_branch_comparison_operator?  Can the ifcvt optimization correctly elide the 2 insn sequence?
Because rs6000 defines "*cbranch_2insn" insn, such insns are generated after expand.

(jump_insn 50 47 51 11 (set (pc)
        (if_then_else (ge (reg:CCFP 156)
                (const_int 0 [0]))
            (label_ref 53)
            (pc))) "/home/guihaoc/gcc/gcc-mainline-base/gmp/mpz/cmpabs_d.c":80:7 884 {*cbranch_2insn}
     (expr_list:REG_DEAD (reg:CCFP 156)
        (int_list:REG_BR_PROB 633507684 (nil)))
 -> 53)

In prepare_cmp_insn, the comparison is verified by insn_operand_matches. If
extra_insn_branch_comparison_operator is not included in "cbranchcc4" predicate,
it hits ICE here.

  if (GET_MODE_CLASS (mode) == MODE_CC)
    {
      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));
      *ptest = test;
      return;
    }

The real conditional move is generated by emit_conditional_move_1. Commonly
"*cbranch_2insn" can't be optimized out and it returns NULL_RTX.

      if (COMPARISON_P (comparison))
        {
          saved_pending_stack_adjust save;
          save_pending_stack_adjust (&save);
          last = get_last_insn ();
          do_pending_stack_adjust ();
          machine_mode cmpmode = comp.mode;
          prepare_cmp_insn (XEXP (comparison, 0), XEXP (comparison, 1),
                            GET_CODE (comparison), NULL_RTX, unsignedp,
                            OPTAB_WIDEN, &comparison, &cmpmode);
          if (comparison)
            {
               rtx res = emit_conditional_move_1 (target, comparison,
                                                  op2, op3, mode);
               if (res != NULL_RTX)
                 return res;
            }
          delete_insns_since (last);
          restore_pending_stack_adjust (&save);

I think that extra_insn_branch_comparison_operator should be included in
"cbranchcc4" predicates as such insns exist. And leave it to
emit_conditional_move which decides whether it can be optimized or not.

Thanks for your comments
Gui Haochen

  reply	other threads:[~2022-11-18  6:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-17  6:39 HAO CHEN GUI
2022-11-17 13:24 ` David Edelsohn
2022-11-18  6:35   ` HAO CHEN GUI [this message]
2022-11-18 12:18     ` Segher Boessenkool
2022-11-18 12:36       ` David Edelsohn
2022-11-21  6:18       ` HAO CHEN GUI
2022-11-21 23:49         ` Segher Boessenkool
2022-11-22  7:50           ` HAO CHEN GUI
2022-11-22  3:11         ` Kewen.Lin
2022-11-22  5:12           ` HAO CHEN GUI
2022-11-22  6:02             ` Kewen.Lin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b3d5f0f8-b16c-6845-ca15-687207e625b5@linux.ibm.com \
    --to=guihaoc@linux.ibm.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@linux.ibm.com \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).