public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] i386: Fix up BFmode comparisons in conditional moves [PR107322]
Date: Fri, 21 Oct 2022 09:15:31 +0200	[thread overview]
Message-ID: <Y1JHE6thlGROTB36@tucnak> (raw)

Hi!

As the testcase shows, when cbranchbf4/cstorebf4 patterns are defined,
we can get ICEs for conditional moves.
The problem is that the generic conditional move expansion just calls
prepare_cmp_insn which just checks that such a cbranch<mode>4 exists
and returns directly such comparison and passes it down to the conditional
move optabs.
The following patch fixes it by punting if the comparisons aren't
ix86_fp_comparison_operator (to tell the generic code it should separately
compare) and to handle the promotion of BFmode comparison operands to
SFmode such that comparison is performed in SFmode.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-10-21  Jakub Jelinek  <jakub@redhat.com>

	PR target/107322
	* config/i386/i386-expand.cc (ix86_prepare_fp_compare_args): For
	BFmode comparisons promote arguments to SFmode and recurse.
	(ix86_expand_int_movcc, ix86_expand_fp_movcc): Return false early
	if comparison operands are BFmode and operands[1] is not
	ix86_fp_comparison_operator.

	* gcc.target/i386/pr107322.c: New test.

--- gcc/config/i386/i386-expand.cc.jj	2022-10-19 11:20:54.602879162 +0200
+++ gcc/config/i386/i386-expand.cc	2022-10-20 12:15:37.750758679 +0200
@@ -2626,6 +2626,35 @@ ix86_prepare_fp_compare_args (enum rtx_c
   machine_mode op_mode = GET_MODE (op0);
   bool is_sse = SSE_FLOAT_MODE_SSEMATH_OR_HF_P (op_mode);
 
+  if (op_mode == BFmode)
+    {
+      rtx op = gen_lowpart (HImode, op0);
+      if (CONST_INT_P (op))
+	op = simplify_const_unary_operation (FLOAT_EXTEND, SFmode,
+					     op0, BFmode);
+      else
+	{
+	  rtx t1 = gen_reg_rtx (SImode);
+	  emit_insn (gen_zero_extendhisi2 (t1, op));
+	  emit_insn (gen_ashlsi3 (t1, t1, GEN_INT (16)));
+	  op = gen_lowpart (SFmode, t1);
+	}
+      *pop0 = op;
+      op = gen_lowpart (HImode, op1);
+      if (CONST_INT_P (op))
+	op = simplify_const_unary_operation (FLOAT_EXTEND, SFmode,
+					     op1, BFmode);
+      else
+	{
+	  rtx t1 = gen_reg_rtx (SImode);
+	  emit_insn (gen_zero_extendhisi2 (t1, op));
+	  emit_insn (gen_ashlsi3 (t1, t1, GEN_INT (16)));
+	  op = gen_lowpart (SFmode, t1);
+	}
+      *pop1 = op;
+      return ix86_prepare_fp_compare_args (code, pop0, pop1);
+    }
+
   /* All of the unordered compare instructions only work on registers.
      The same is true of the fcomi compare instructions.  The XFmode
      compare instructions require registers except when comparing
@@ -3164,6 +3193,10 @@ ix86_expand_int_movcc (rtx operands[])
 	  && !TARGET_64BIT))
     return false;
 
+  if (GET_MODE (op0) == BFmode
+      && !ix86_fp_comparison_operator (operands[1], VOIDmode))
+    return false;
+
   start_sequence ();
   compare_op = ix86_expand_compare (code, op0, op1);
   compare_seq = get_insns ();
@@ -4238,6 +4271,10 @@ ix86_expand_fp_movcc (rtx operands[])
   rtx op0 = XEXP (operands[1], 0);
   rtx op1 = XEXP (operands[1], 1);
 
+  if (GET_MODE (op0) == BFmode
+      && !ix86_fp_comparison_operator (operands[1], VOIDmode))
+    return false;
+
   if (SSE_FLOAT_MODE_SSEMATH_OR_HF_P (mode))
     {
       machine_mode cmode;
--- gcc/testsuite/gcc.target/i386/pr107322.c.jj	2022-10-20 12:28:46.829983399 +0200
+++ gcc/testsuite/gcc.target/i386/pr107322.c	2022-10-20 12:29:44.287201650 +0200
@@ -0,0 +1,33 @@
+/* PR target/107322 */
+/* { dg-do compile } */
+/* { dg-options "-fexcess-precision=16 -O -msse2 -mfpmath=sse" } */
+
+int i, j;
+float k, l;
+__bf16 f;
+
+void
+foo (void)
+{
+  i *= 0 >= f;
+}
+
+void
+bar (void)
+{
+  i *= 0 <= f;
+}
+
+void
+baz (int x, int y)
+{
+  i = 0 >= f ? x : y;
+  j = 0 <= f ? x + 2 : y + 3;
+}
+
+void
+qux (float x, float y)
+{
+  k = 0 >= f ? x : y;
+  l = 0 <= f ? x + 2 : y + 3;
+}

	Jakub


             reply	other threads:[~2022-10-21  7:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21  7:15 Jakub Jelinek [this message]
2022-10-21  8:23 ` Uros Bizjak
2022-11-19  8:52   ` [PATCH] i386: Outline fast BF -> SF conversion and fix up sNaN handling in it [PR107628] Jakub Jelinek
2022-11-19  8:57     ` Uros Bizjak

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=Y1JHE6thlGROTB36@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ubizjak@gmail.com \
    /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).