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

On Wed, Jul 25, 2018 at 10:28:30AM +0200, Richard Biener wrote:
> 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! ;)

I only have target-specific ones.  Most *simple* ones will already be
optimised by current code (via 3->2 combination).  But I've now got one
that trunk does not optimise, and it can be confirmed with looking at
the resulting machine code even (no need to look at the combine dump,
which is a very good thing).  And it is a proper thing to test even: it
tests that some source is compiled to properly optimised machine code.

Any other kind of testcase is worse than useless, of course.

Testing it results in working code isn't very feasible or useful either.


Segher

  reply	other threads:[~2018-07-25  9:50 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
2018-07-25  9:50   ` Segher Boessenkool [this message]
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=20180725095013.GR16221@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@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).