public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Ignore debug insns with CONCAT and CONCATN for insn scheduling
Date: Tue, 27 Sep 2022 01:43:44 +0200	[thread overview]
Message-ID: <YzI5MCDHlmbMbYhk@tucnak> (raw)
In-Reply-To: <fcaf3d36-2076-8846-6413-7441557794ae@gmail.com>

On Mon, Sep 26, 2022 at 05:23:45PM -0600, Jeff Law via Gcc-patches wrote:
> 
> On 9/26/22 13:52, H.J. Lu wrote:
> > On Sat, Sep 24, 2022 at 1:37 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
> > > 
> > > On 9/21/22 16:11, H.J. Lu wrote:
> > > > On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches
> > > > <gcc-patches@gcc.gnu.org> wrote:
> > > > > 
> > > > > On 9/2/2022 8:36 AM, H.J. Lu via Gcc-patches wrote:
> > > > > > CONCAT and CONCATN never appear in the insn chain.  They are only used
> > > > > > in debug insn.  Ignore debug insns with CONCAT and CONCATN for insn
> > > > > > scheduling to avoid different insn orders with and without debug insn.
> > > > > > 
> > > > > > gcc/
> > > > > > 
> > > > > >         PR rtl-optimization/106746
> > > > > >         * sched-deps.cc (sched_analyze_2): Ignore debug insns with CONCAT
> > > > > >         and CONCATN.
> > > > > Shouldn't we be ignoring everything in a debug insn?   I don't see why
> > > > > CONCAT/CONCATN are special here.
> > > > Debug insns are processed by insn scheduling.   I think it is to improve debug
> > > > experiences.  It is just that there are no matching usages of CONCAT/CONCATN
> > > > in non-debug insns.
> > > But from a dependency standpoint ISTM all debug insn can be ignored.  I
> > > still don't see why concat/concatn should be special here.
> > > 
> > I tried to ignore everything in a debug insn.  It caused many regressions in
> > the GCC testsuite.
> Not terribly useful -- what failed and why?

I think the design for debug insns in the scheduler is that they do affect
scheduling decisions, but what is in debug insns should only affect actual
scheduling of the debug insns and not the rest.
So it wouldn't surprise me if ignoring everything in a debug insn broke a
lot.  But I admit I never fully understood how it works, hopefully Alex or
Vlad do.

	Jakub


  reply	other threads:[~2022-09-26 23:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-02 14:36 H.J. Lu
2022-09-07 17:02 ` Jeff Law
2022-09-21 22:11   ` H.J. Lu
2022-09-24 20:37     ` Jeff Law
2022-09-26 19:52       ` H.J. Lu
2022-09-26 23:23         ` Jeff Law
2022-09-26 23:43           ` Jakub Jelinek [this message]
2022-09-27  1:40             ` 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=YzI5MCDHlmbMbYhk@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=jeffreyalaw@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).