public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: "Bin.Cheng" <amker.cheng@gmail.com>,
	Eric Botcazou <ebotcazou@adacore.com>, Jeff Law <law@redhat.com>,
	Segher Boessenkool <segher@kernel.crashing.org>
Cc: "bin.cheng" <bin.cheng@linux.alibaba.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch
Date: Thu, 22 Jul 2021 15:04:32 +0200	[thread overview]
Message-ID: <CAFiYyc1zOfKttY7uE7Udh+tse-3VO2zWnXiEBX4PWLN9krpOww@mail.gmail.com> (raw)
In-Reply-To: <CAHFci2-2J-TAXksvjv1wPrKqugaFc3U-R_b+F0zBu6xiL6O+qg@mail.gmail.com>

On Thu, Jul 22, 2021 at 9:02 AM Bin.Cheng via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Gentle ping.  Any suggestions would be appreciated.

So just to say something - does the existing code mean that any use of
the alias info on prologue/epilogue insns is wrong?  We have

  /* The prologue/epilogue insns are not threaded onto the
     insn chain until after reload has completed.  Thus,
     there is no sense wasting time checking if INSN is in
     the prologue/epilogue until after reload has completed.  */
  bool could_be_prologue_epilogue = ((targetm.have_prologue ()
                                      || targetm.have_epilogue ())
                                     && reload_completed);

so when !could_be_prologue_epilogue then passes shouldn't run into
them if the comment is correct.  But else even epilogue stmts could appear
anywhere (like scheduled around)?  So why's skipping those OK?

Are passes supposed to check whether they are dealing with pro/epilogue
insns and not touch them?  CCing people that might know.

Richard.

> Thanks,
> bin
>
> On Wed, Jul 14, 2021 at 5:15 PM bin.cheng via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > Hi,
> > I ran into a wrong code bug in code with deep template instantiation when working on sdx::simd.
> > The root cause as described in commit summary is we skip prologue insns in init_alias_analysis.
> > This simple patch fixes the issue, however, it's hard to reduce a case because of heavy use of
> > templates.
> > Bootstrap and test on x86_64, is it OK?
> >
> > Thanks,
> > bin

  reply	other threads:[~2021-07-22 13:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14  9:14 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch bin.cheng
2021-07-22  7:01 ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Bin.Cheng
2021-07-22 13:04   ` Richard Biener [this message]
2021-07-22 23:36     ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Segher Boessenkool
2021-07-23 16:27     ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Jeff Law
2021-07-26 22:55       ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Segher Boessenkool
2021-07-27 15:20         ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Jeff Law
2021-07-22 23:51 ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Segher Boessenkool
2021-07-23  6:50   ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Bin.Cheng
2021-07-23 16:29 ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Jeff Law
2021-07-26  1:47   ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Bin.Cheng
2021-07-26 15:07     ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Jeff Law
2021-07-27  8:50       ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Bin.Cheng
2021-07-27  8:59         ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Richard Biener
2021-07-27 15:21         ` 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Jeff Law

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=CAFiYyc1zOfKttY7uE7Udh+tse-3VO2zWnXiEBX4PWLN9krpOww@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=amker.cheng@gmail.com \
    --cc=bin.cheng@linux.alibaba.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --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).