public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls
Date: Mon, 23 Jan 2023 10:28:01 +0000 (UTC)	[thread overview]
Message-ID: <nycvar.YFH.7.77.849.2301231023510.6551@jbgna.fhfr.qr> (raw)
In-Reply-To: <Y85fhDhMsPe4GO20@tucnak>

On Mon, 23 Jan 2023, Jakub Jelinek wrote:

> On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote:
> > The following deals with .LOOP_DIST_ALIAS surviving vectorization
> > because any of the loops involved were elided between loop distribution
> > and vectorization.  As opposed to .LOOP_VECTORIZED which exists only
> > between if-conversion and vectorization with no intermediate passes
> > this is more difficult to deal with in advance and thus cleaning
> > up after vectorization looks better.  There's the unconditional
> > vector lowering pass which looks like a good place for this (for
> > SIMD uid we have pass_simduid_cleanup).
> > 
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > 
> > OK?
> 
> I admit I didn't know something like LOOP_DIST_ALIAS even exist until
> today.
> Anyway, I wonder if there is still time to clean up during/after
> veclower21.

That's what the patch does, but maybe I misunderstood the question.

> I see fold_loop_internal_call propagates the return value to immediate
> uses and cfg_changed means we'll clean up the cfg, is that enough?

It's enough to get rid of the internal function call which will ICE
if it reaches RTL expansion.  The earliest point to get rid of them
is in the loop vectorizer but for the testcase at hand this requires
a walk of the whole IL where we cut the whole vectorizer pass with
the number-of-loops in function check currently.

Richard.

  reply	other threads:[~2023-01-23 10:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-23 10:09 Richard Biener
2023-01-23 10:20 ` Jakub Jelinek
2023-01-23 10:28   ` Richard Biener [this message]
2023-01-23 10:29     ` Jakub Jelinek

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=nycvar.YFH.7.77.849.2301231023510.6551@jbgna.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.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).