public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] combine: Allow combining two insns to two insns
Date: Wed, 25 Jul 2018 08:28:00 -0000	[thread overview]
Message-ID: <CAFiYyc3rQLufmnc0V7LpvZjCzG_Eo6_LM9EYz7XGBK8rVyi6qA@mail.gmail.com> (raw)
In-Reply-To: <402e00c62fa533333b1e1dd69f468f7f4e43939b.1532449714.git.segher@kernel.crashing.org>

On Tue, Jul 24, 2018 at 7:18 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> This patch allows combine to combine two insns into two.  This helps
> in many cases, by reducing instruction path length, and also allowing
> further combinations to happen.  PR85160 is a typical example of code
> that it can improve.
>
> This patch does not allow such combinations if either of the original
> instructions was a simple move instruction.  In those cases combining
> the two instructions increases register pressure without improving the
> code.  With this move test register pressure does no longer increase
> noticably as far as I can tell.
>
> (At first I also didn't allow either of the resulting insns to be a
> move instruction.  But that is actually a very good thing to have, as
> should have been obvious).
>
> Tested for many months; tested on about 30 targets.
>
> I'll commit this later this week if there are no objections.

Sounds good - but, _any_ testcase?  Please! ;)

Richard.

>
> Segher
>
>
> 2018-07-24  Segher Boessenkool  <segher@kernel.crashing.org>
>
>         PR rtl-optimization/85160
>         * combine.c (is_just_move): New function.
>         (try_combine): Allow combining two instructions into two if neither of
>         the original instructions was a move.
>
> ---
>  gcc/combine.c | 22 ++++++++++++++++++++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/combine.c b/gcc/combine.c
> index cfe0f19..d64e84d 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -2604,6 +2604,17 @@ can_split_parallel_of_n_reg_sets (rtx_insn *insn, int n)
>    return true;
>  }
>
> +/* Return whether X is just a single set, with the source
> +   a general_operand.  */
> +static bool
> +is_just_move (rtx x)
> +{
> +  if (INSN_P (x))
> +    x = PATTERN (x);
> +
> +  return (GET_CODE (x) == SET && general_operand (SET_SRC (x), VOIDmode));
> +}
> +
>  /* Try to combine the insns I0, I1 and I2 into I3.
>     Here I0, I1 and I2 appear earlier than I3.
>     I0 and I1 can be zero; then we combine just I2 into I3, or I1 and I2 into
> @@ -2668,6 +2679,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, rtx_insn *i0,
>    int swap_i2i3 = 0;
>    int split_i2i3 = 0;
>    int changed_i3_dest = 0;
> +  bool i2_was_move = false, i3_was_move = false;
>
>    int maxreg;
>    rtx_insn *temp_insn;
> @@ -3059,6 +3071,10 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, rtx_insn *i0,
>        return 0;
>      }
>
> +  /* Record whether i2 and i3 are trivial moves.  */
> +  i2_was_move = is_just_move (i2);
> +  i3_was_move = is_just_move (i3);
> +
>    /* Record whether I2DEST is used in I2SRC and similarly for the other
>       cases.  Knowing this will help in register status updating below.  */
>    i2dest_in_i2src = reg_overlap_mentioned_p (i2dest, i2src);
> @@ -4014,8 +4030,10 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, rtx_insn *i0,
>            && XVECLEN (newpat, 0) == 2
>            && GET_CODE (XVECEXP (newpat, 0, 0)) == SET
>            && GET_CODE (XVECEXP (newpat, 0, 1)) == SET
> -          && (i1 || set_noop_p (XVECEXP (newpat, 0, 0))
> -                 || set_noop_p (XVECEXP (newpat, 0, 1)))
> +          && (i1
> +              || set_noop_p (XVECEXP (newpat, 0, 0))
> +              || set_noop_p (XVECEXP (newpat, 0, 1))
> +              || (!i2_was_move && !i3_was_move))
>            && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 0))) != ZERO_EXTRACT
>            && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 0))) != STRICT_LOW_PART
>            && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 1))) != ZERO_EXTRACT
> --
> 1.8.3.1
>

  parent reply	other threads:[~2018-07-25  8:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-24 17:18 Segher Boessenkool
2018-07-24 21:13 ` Jeff Law
2018-07-25  8:28 ` Richard Biener [this message]
2018-07-25  9:50   ` Segher Boessenkool
2018-07-25 10:37     ` Richard Biener
2018-07-31 12:39   ` H.J. Lu
2018-07-31 14:08     ` Segher Boessenkool
2018-07-25 13:47 ` David Malcolm
2018-07-25 14:19   ` Segher Boessenkool
2018-07-30 16:09 ` Segher Boessenkool
2018-07-31 12:34   ` Christophe Lyon
2018-07-31 12:59     ` Richard Sandiford
2018-07-31 13:57     ` Segher Boessenkool
2018-07-31 15:37       ` Richard Earnshaw (lists)
2018-08-01  8:27       ` Christophe Lyon
2018-08-01  9:40         ` Segher Boessenkool
2018-08-01 10:52           ` Christophe Lyon
2018-08-02  5:52 ` Toon Moene

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=CAFiYyc3rQLufmnc0V7LpvZjCzG_Eo6_LM9EYz7XGBK8rVyi6qA@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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).