public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: liuhongt <hongtao.liu@intel.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Split vector load from parm_del to elemental loads to avoid STLF stalls.
Date: Thu, 31 Mar 2022 12:44:54 +0200	[thread overview]
Message-ID: <CAFiYyc0euWhV44V8LY6Ue8JOx9+N+wcor9Kc8238WX0dOaxGUA@mail.gmail.com> (raw)
In-Reply-To: <20220331055117.6942-1-hongtao.liu@intel.com>

On Thu, Mar 31, 2022 at 7:51 AM liuhongt <hongtao.liu@intel.com> wrote:
>
> Since cfg is freed before machine_reorg, just do a rough calculation
> of the window according to the layout.
> Also according to an experiment on CLX, set window size to 64.
>
> Currently only handle V2DFmode load since it doesn't need any scratch
> registers, and it's sufficient to recover cray performance for -O2
> compared to GCC11.
>
> Bootstrap and regtest on x86_64-pc-linux-gnu{-m32,}.
> No impact for SPEC2017(same binary for both O2 and Ofast).
> Ok for trunk?
>
> gcc/ChangeLog:
>
>         PR target/101908
>         * config/i386/i386.cc (ix86_split_stlf_stall_load): New
>         function
>         (ix86_reorg): Call ix86_split_stlf_stall_load.
>
> gcc/testsuite/ChangeLog:
>
>         * gcc.target/i386/pr101908-1.c: New test.
>         * gcc.target/i386/pr101908-2.c: New test.
> ---
>  gcc/config/i386/i386.cc                    | 47 ++++++++++++++++++++++
>  gcc/testsuite/gcc.target/i386/pr101908-1.c | 12 ++++++
>  gcc/testsuite/gcc.target/i386/pr101908-2.c | 12 ++++++
>  3 files changed, 71 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr101908-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr101908-2.c
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index 5a561966eb4..f9169b04d43 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -21933,7 +21933,53 @@ ix86_seh_fixup_eh_fallthru (void)
>        emit_insn_after (gen_nops (const1_rtx), insn);
>      }
>  }
> +/* Split vector load from parm_decl to elemental loads to avoid STLF
> +   stalls.  */
> +static void
> +ix86_split_stlf_stall_load ()
> +{
> +  basic_block bb;
> +  unsigned window = 0;
> +  FOR_EACH_BB_FN (bb, cfun)
> +    {
> +      rtx_insn *insn;
> +      FOR_BB_INSNS (bb, insn)
> +       {
> +         if (!NONDEBUG_INSN_P (insn))
> +           continue;
> +         window++;
> +         /* Insert 64 vaddps %xmm18, %xmm19, %xmm20(no dependence between each
> +            other, just emulate for pipeline) before stalled load, stlf stall
> +            case is as fast as no stall cases on CLX.
> +            Since CFG is freed before machine_reorg, just do a rough
> +            calculation of the window according to the layout.  */
> +         if (window > 64)
> +           return;

I wonder if we should also return for any_uncondjump_p (insn)
(not sure if that captures returnjump_p), or maybe just explicitely
allow any_condjump_p and reject other PC setters.

Likewise we might want to stop at a LABEL that can be backwards reached.

I suppose people more familiar with cfgrtl can suggest something better.

> +         rtx set = single_set (insn);
> +         if (!set)
> +           continue;
> +         rtx src = SET_SRC (set);
> +         if (!MEM_P (src)
> +             /* Only handle V2DFmode load since it doesn't need any scratch
> +                register.  */
> +             || GET_MODE (src) != E_V2DFmode
> +             || !MEM_EXPR (src)
> +             || TREE_CODE (get_base_address (MEM_EXPR (src))) != PARM_DECL)

I wonder if we have (easy) ways to detect whether XEXP (src, 0) is
frame/stack based
rather than requiring a MEM_EXPR.  There is may_be_sp_based_p ()
exported from alias.c
for example, but I'm not sure whether that works after RA & frame elimination.

> +           continue;
> +
> +         rtx zero = CONST0_RTX (V2DFmode);
> +         rtx dest = SET_DEST (set);
> +         rtx m = adjust_address (src, DFmode, 0);
> +         emit_insn_before (gen_sse2_loadlpd (dest, zero, m), insn);

Can SSE1 also do this?

> +         m = adjust_address (src, DFmode, 8);
> +         PATTERN (insn) = gen_sse2_loadhpd (dest, dest, m);
> +         INSN_CODE (insn) = -1;
> +         gcc_assert (recog_memoized (insn) != -1);

I think we want to dump something into dump_file when we split an insn here.

> +       }
> +    }
> +
> +}
>  /* Implement machine specific optimizations.  We implement padding of returns
>     for K8 CPUs and pass to avoid 4 jumps in the single 16 byte window.  */
>  static void
> @@ -21948,6 +21994,7 @@ ix86_reorg (void)
>
>    if (optimize && optimize_function_for_speed_p (cfun))
>      {
> +      ix86_split_stlf_stall_load ();
>        if (TARGET_PAD_SHORT_FUNCTION)
>         ix86_pad_short_function ();

btw. this function suggests we do have edges, so doing something "better"
than FOR_EACH_BB_FN, aka walking blocks in layout order, might be
possible after all.  For example ix86_avoid_jump_mispredicts just walks
the function by looking at get_insns(), that might be more closely what
"as laid out" is.

>        else if (TARGET_PAD_RETURNS)
> diff --git a/gcc/testsuite/gcc.target/i386/pr101908-1.c b/gcc/testsuite/gcc.target/i386/pr101908-1.c
> new file mode 100644
> index 00000000000..33d9684f0ad
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr101908-1.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -msse2 -mno-avx" } */
> +/* { dg-final { scan-assembler-not {(?n)movhpd[ \t]} } } */
> +
> +struct X { double x[2]; };
> +typedef double v2df __attribute__((vector_size(16)));
> +
> +v2df __attribute__((noipa))
> +foo (struct X* x, struct X* y)
> +{
> +  return (v2df) {x->x[1], x->x[0] } + (v2df) { y->x[1], y->x[0] };
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr101908-2.c b/gcc/testsuite/gcc.target/i386/pr101908-2.c
> new file mode 100644
> index 00000000000..45060b73c06
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr101908-2.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -msse2 -mno-avx" } */
> +/* { dg-final { scan-assembler-times {(?n)movhpd[ \t]+} "2" } }  */
> +
> +struct X { double x[4]; };
> +typedef double v2df __attribute__((vector_size(16)));
> +
> +v2df __attribute__((noipa))
> +foo (struct X x, struct X y)
> +{
> +  return (v2df) {x.x[1], x.x[0] } + (v2df) { y.x[1], y.x[0] };
> +}
> --
> 2.18.1
>

  reply	other threads:[~2022-03-31 10:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31  5:51 liuhongt
2022-03-31 10:44 ` Richard Biener [this message]
2022-04-01  6:29   ` Hongtao Liu
2022-04-01  6:46     ` liuhongt
2022-04-01  6:53       ` Richard Biener
2022-04-01  7:14         ` Hongtao Liu
2022-04-01  7:20           ` Richard Biener
2022-04-01  7:51             ` [PATCH V3] " liuhongt
2022-04-04 11:47               ` Hongtao Liu
2022-04-01  6:47     ` [PATCH] " Richard Biener

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=CAFiYyc0euWhV44V8LY6Ue8JOx9+N+wcor9Kc8238WX0dOaxGUA@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hongtao.liu@intel.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).