public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Pinski <pinskia@gmail.com>
To: Oleg Endo <oleg.endo@t-online.de>
Cc: Richard Biener <richard.guenther@gmail.com>,
	Manolis Tsamis <manolis.tsamis@vrull.eu>,
	 GCC Patches <gcc-patches@gcc.gnu.org>,
	Andrew Pinski <quic_apinski@quicinc.com>,
	 Philipp Tomsich <philipp.tomsich@vrull.eu>,
	Tamar Christina <Tamar.Christina@arm.com>,
	 Jiangning Liu <jiangning.liu@amperecomputing.com>
Subject: Re: [PATCH] Add extra copy of the ifcombine pass after pre [PR102793]
Date: Thu, 16 May 2024 13:03:09 +0200	[thread overview]
Message-ID: <CA+=Sn1kpVSHNFrvW5WJN46DBADffUT_CR6LEx9YeJe2JJ-JRVA@mail.gmail.com> (raw)
In-Reply-To: <b1a6517e92f8fdba1dd6c825232445ae4613fadf.camel@t-online.de>

[-- Attachment #1: Type: text/plain, Size: 3347 bytes --]

On Thu, May 16, 2024, 12:55 PM Oleg Endo <oleg.endo@t-online.de> wrote:

>
> On Thu, 2024-05-16 at 10:35 +0200, Richard Biener wrote:
> > On Fri, Apr 5, 2024 at 8:14 PM Andrew Pinski <pinskia@gmail.com> wrote:
> > >
> > > On Fri, Apr 5, 2024 at 5:28 AM Manolis Tsamis <manolis.tsamis@vrull.eu>
> wrote:
> > > >
> > > > If we consider code like:
> > > >
> > > >     if (bar1 == x)
> > > >       return foo();
> > > >     if (bar2 != y)
> > > >       return foo();
> > > >     return 0;
> > > >
> > > > We would like the ifcombine pass to convert this to:
> > > >
> > > >     if (bar1 == x || bar2 != y)
> > > >       return foo();
> > > >     return 0;
> > > >
> > > > The ifcombine pass can handle this transformation but it is ran very
> early and
> > > > it misses the opportunity because there are two seperate blocks for
> foo().
> > > > The pre pass is good at removing duplicate code and blocks and due
> to that
> > > > running ifcombine again after it can increase the number of
> successful
> > > > conversions.
> > >
> > > I do think we should have something similar to re-running
> > > ssa-ifcombine but I think it should be much later, like after the loop
> > > optimizations are done.
> > > Maybe just a simplified version of it (that does the combining and not
> > > the optimizations part) included in isel or pass_optimize_widening_mul
> > > (which itself should most likely become part of isel or renamed since
> > > it handles more than just widening multiply these days).
> >
> > I've long wished we had a (late?) pass that can also undo if-conversion
> > (basically do what RTL expansion would later do).  Maybe
> > gimple-predicate-analysis.cc (what's used by uninit analysis) can
> > represent mixed CFG + if-converted conditions so we can optimize
> > it and code-gen the condition in a more optimal manner much like
> > we have if-to-switch, switch-conversion and switch-expansion.
> >
> > That said, I agree that re-running ifcombine should be later.  And
> there's
> > still the old task of splitting tail-merging from PRE (and possibly
> making
> > it more effective).
>
> Sorry to butt in, but it might be little bit relevant and caught my
> attention.
>
> I've got this SH patch sitting around
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55543
>
> The idea is basically to run an additional loop pass after combine and
> split1.  The main purpose is to hoist constant loads out of loops. Such
> constant loads might be formed (in this particular case) during combine
> transformations.
>
> The patch adds a new file gcc/config/sh/sh_loop.cc, which has some boiler-
> plate code copy pasted from other places to get the loop pass setup and
> going.
>
> Any thoughts on this way of doing it?
>

I have been looking at a similar issue on aarch64 for a few cases, csinc
and nand. What I decided to do for nand was not depend on combine in the
end and create a new infrastructure to expand better to rtl from gimple and
maybe even have target specific pattern matching on the gimple level. So
the constant is not part of the other instruction.

I should have a write up/first draft of an implementation by August time
frame or so. The write up will most likely be earlier.

Thanks,
Andrew



>
> Best regards,
> Oleg Endo
>

      reply	other threads:[~2024-05-16 11:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05 12:26 Manolis Tsamis
2024-04-05 12:43 ` Richard Biener
2024-04-05 13:33   ` Manolis Tsamis
2024-04-05 18:13 ` Andrew Pinski
2024-05-16  8:35   ` Richard Biener
2024-05-16 10:55     ` Oleg Endo
2024-05-16 11:03       ` Andrew Pinski [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='CA+=Sn1kpVSHNFrvW5WJN46DBADffUT_CR6LEx9YeJe2JJ-JRVA@mail.gmail.com' \
    --to=pinskia@gmail.com \
    --cc=Tamar.Christina@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jiangning.liu@amperecomputing.com \
    --cc=manolis.tsamis@vrull.eu \
    --cc=oleg.endo@t-online.de \
    --cc=philipp.tomsich@vrull.eu \
    --cc=quic_apinski@quicinc.com \
    --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).