public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Uros Bizjak <ubizjak@gmail.com>
To: Roger Sayle <roger@nextmovesoftware.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [x86 PATCH] Double word logical operation clean-ups in i386.md.
Date: Tue, 28 Jun 2022 17:38:15 +0200	[thread overview]
Message-ID: <CAFULd4b_x5W+n9RD6h4RJ4kWSLnb76GgEYiS7NwQrbNhwZAh3Q@mail.gmail.com> (raw)
In-Reply-To: <009501d88ae3$13aeed30$3b0cc790$@nextmovesoftware.com>

On Tue, Jun 28, 2022 at 1:34 PM Roger Sayle <roger@nextmovesoftware.com> wrote:
>
>
> Hi Uros,
> As you've requested/suggested, here's a patch that tidies up and
> unifies doubleword handling in i386.md; converting all doubleword
> splitters for logic operations to post-reload form, generalizing
> their define_insn_and_split templates to <dwi> form (supporting
> TARGET_64BIT ? TImode : DImode), and where required tweaking the
> corresponding expanders to use SDWIM to support TImode doubleword
> operations.  These changes incorporate your feedback from
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596205.html
> where I included many/several of these clean-ups, in a patch to
> add a new optimization.  I agree, it's better to split these out
> (this patch), and I'll resubmit the (smaller) optimization patch
> as a follow-up.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures.  Ok for mainline?
>
>
> 2022-06-28  Roger Sayle  <roger@nextmovesoftware.com>
>
> gcc/ChangeLog
>         * config/i386/i386.md (general_szext_operand): Add TImode
>         support using x86_64_hilo_general_operand predicate.
>         (*cmp<dwi>_doubleword): Use x86_64_hilo_general_operand predicate.
>         (*add<dwi>3_doubleword): Improved optimization of zero addition.
>         (and<mode>3): Use SDWIM mode iterator to add support for double
>         word bit-wise AND in TImode.  Use force_reg when double word
>         immediate operand isn't x86_64_hilo_general_operand.
>         (and<dwi>3_doubleword): Generalized from anddi3_doubleword and
>         converted into a post-reload splitter.
>         (*andn<mode>3_doubleword): Generalized from *andndi3_doubleword.
>         (define_split): Generalize DImode splitters for andn to <DWI>.
>         One splitter for TARGET_BMI, the other for !TARGET_BMI.
>         (<any_or><mode>3): Use SDWIM mode iterator to add suppport for
>         double word bit-wise XOR and bit-wise IOR in TImode.  Use
>         force_reg when double word immediate operand isn't
>         x86_64_hilo_general_operand.
>         (*<any_or>di3_doubleword): Generalized from <any_or>di3_doubleword.
>         (one_cmpl<mode>2): Use SDWIM mode iterator to add support for
>         double word bit-wise NOT in TImode.
>         (one_cmpl<dwi>2_doubleword): Generalize from one_cmpldi2_doubleword
>         and converted into a post-reload splitter.


 (define_expand "and<mode>3"
-  [(set (match_operand:SWIM1248x 0 "nonimmediate_operand")
-    (and:SWIM1248x (match_operand:SWIM1248x 1 "nonimmediate_operand")
-               (match_operand:SWIM1248x 2 "<general_szext_operand>")))]
+  [(set (match_operand:SDWIM 0 "nonimmediate_operand")
+    (and:SDWIM (match_operand:SDWIM 1 "nonimmediate_operand")
+           (match_operand:SDWIM 2 "<general_szext_operand>")))]
   ""
 {
   machine_mode mode = <MODE>mode;

-  if (<MODE>mode == DImode && !TARGET_64BIT)
-    ;
-  else if (const_int_operand (operands[2], <MODE>mode)
-       && register_operand (operands[0], <MODE>mode)
-       && !(TARGET_ZERO_EXTEND_WITH_AND
-        && optimize_function_for_speed_p (cfun)))
+  if (GET_MODE_SIZE (<MODE>mode) > UNITS_PER_WORD
+      && !x86_64_hilo_general_operand (operands[2], <MODE>mode))
+    operands[2] = force_reg (<MODE>mode, operands[2]);

You don't have to do that - when the predicate can't be satisfied, the
middle-end pushes the value to a register as a last resort by default.

+  bool emit_insn_deleted_note_p = false;
+
+  split_double_mode (<DWI>mode, &operands[0], 3, &operands[0], &operands[3]);

   if (operands[2] == const0_rtx)
     emit_move_insn (operands[0], const0_rtx);
   else if (operands[2] == constm1_rtx)
-    emit_move_insn (operands[0], operands[1]);
+    {
+      if (!rtx_equal_p (operands[0], operands[1]))
+    emit_move_insn (operands[0], operands[1]);
+      else
+    emit_insn_deleted_note_p = true;
+    }

Please note that when operands[2] is an immediate, constraints after
reload *guarantee* that operands[1] match operands[0]. So, the insn
should always be deleted (I think that this functionality was in your
<any_or> patch - it is unneeded there, too).

+(define_insn "*andn<mode>3_doubleword"
+  [(set (match_operand:DWI 0 "register_operand")
+    (and:DWI
+      (not:DWI (match_operand:DWI 1 "register_operand"))
+      (match_operand:DWI 2 "nonimmediate_operand")))
    (clobber (reg:CC FLAGS_REG))]
-  "!TARGET_64BIT && TARGET_STV && TARGET_SSE2
-   && ix86_pre_reload_split ()"
+  "ix86_pre_reload_split ()"
   "#")

Please introduce two ANDN double-word insn-and-split patterns, one for
BMI and one for !BMI. The one for BMI should be moved to a post-reload
splitter, too. As we figured out, *all* double-word patterns should
either be of pre-reload or of post-reload type.

 (define_split
-  [(set (match_operand:DI 0 "register_operand")
-    (and:DI
-      (not:DI (match_operand:DI 1 "register_operand"))
-      (match_operand:DI 2 "nonimmediate_operand")))
+  [(set (match_operand:DWI 0 "register_operand")
+    (and:DWI
+      (not:DWI (match_operand:DWI 1 "register_operand"))
+      (match_operand:DWI 2 "nonimmediate_operand")))
    (clobber (reg:CC FLAGS_REG))]
-  "!TARGET_64BIT && !TARGET_BMI && TARGET_STV && TARGET_SSE2
+  "!TARGET_BMI

Without BMI, the ANDN should be split to a double-word NOT + AND
before reload (and these two insns are split to single-word operations
after reload). This simplifies splitting logic quite a bit.

 (define_expand "<code><mode>3"
-  [(set (match_operand:SWIM1248x 0 "nonimmediate_operand")
-    (any_or:SWIM1248x (match_operand:SWIM1248x 1 "nonimmediate_operand")
-              (match_operand:SWIM1248x 2 "<general_operand>")))]
+  [(set (match_operand:SDWIM 0 "nonimmediate_operand")
+    (any_or:SDWIM (match_operand:SDWIM 1 "nonimmediate_operand")
+              (match_operand:SDWIM 2 "<general_operand>")))]

Use <general_szext_operand> here ...

   ""
-  "ix86_expand_binary_operator (<CODE>, <MODE>mode, operands); DONE;")
+{

-(define_insn_and_split "*<code>di3_doubleword"
-  [(set (match_operand:DI 0 "nonimmediate_operand" "=ro,r")
-    (any_or:DI
-     (match_operand:DI 1 "nonimmediate_operand" "0,0")
-     (match_operand:DI 2 "x86_64_szext_general_operand" "re,o")))
+  if (GET_MODE_SIZE (<MODE>mode) > UNITS_PER_WORD
+      && !x86_64_hilo_general_operand (operands[2], <MODE>mode))
+    operands[2] = force_reg (<MODE>mode, operands[2]);

... to avoid the above fixup.

+(define_insn_and_split "*<code><mode>3_doubleword"
+  [(set (match_operand:<DWI> 0 "nonimmediate_operand" "=ro,r")
+    (any_or:<DWI>
+     (match_operand:<DWI> 1 "nonimmediate_operand" "%0,0")
+     (match_operand:<DWI> 2 "x86_64_hilo_general_operand" "r<di>,o")))

<general_szext_operand> for consistency.

Otherwise OK.

Uros.

      reply	other threads:[~2022-06-28 15:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-28 11:34 Roger Sayle
2022-06-28 15:38 ` Uros Bizjak [this message]

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=CAFULd4b_x5W+n9RD6h4RJ4kWSLnb76GgEYiS7NwQrbNhwZAh3Q@mail.gmail.com \
    --to=ubizjak@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=roger@nextmovesoftware.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).