public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: Jose Marchesi <jose.marchesi@oracle.com>,
	 "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH V2] Disable sched1 in functions that call setjmp
Date: Fri, 23 Dec 2022 18:03:20 +0300 (MSK)	[thread overview]
Message-ID: <f41bb491-fd14-801e-ed78-797a1408dffa@ispras.ru> (raw)
In-Reply-To: <D53E1E66-F51C-47BF-99B1-EA49BDB29C9E@oracle.com>

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

On Fri, 23 Dec 2022, Qing Zhao wrote:
> >> I am a little confused, you mean pre-RA scheduler does not look at the data flow
> >> information at all when scheduling insns across calls currently?
> > 
> > I think it does not inspect liveness info, and may extend lifetime of a pseudo
> > across a call, transforming
> > 
> >  call foo
> >  reg = 1
> >  ...
> >  use reg
> > 
> > to
> > 
> >  reg = 1
> >  call foo
> >  ...
> >  use reg
> > 
> > but this is undesirable, because now register allocation cannot select a
> > call-clobbered register for 'reg’.
> Okay, thanks for the explanation.
> 
> Then, why not just check the liveness info instead of inhibiting all scheduling across calls?

Because there's almost nothing to gain from pre-RA scheduling across calls in
the first place. Remember that the call transfers control flow elsewhere and
therefore the scheduler has no idea about the pipeline state after the call
and after the return, so modeling-wise it's a gamble.

For instructions that lie on a critical path such scheduling can be useful when
it substantially reduces the difference between the priority of the call and
nearby instructions of the critical path. But we don't track which instructions
are on critical path(s) and which are not.

(scheduling across calls in sched2 is somewhat dubious as well, but
it doesn't risk register pressure issues, and on VLIW CPUs it at least
can result in better VLIW packing)

Alexander

  reply	other threads:[~2022-12-23 15:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22 17:32 Jose E. Marchesi
2022-12-22 17:56 ` Alexander Monakov
2022-12-22 19:28   ` Qing Zhao
2022-12-23  7:33     ` Alexander Monakov
2022-12-23 14:34       ` Qing Zhao
2022-12-23 15:03         ` Alexander Monakov [this message]
2022-12-23 17:27           ` Jose E. Marchesi
2022-12-23 17:31             ` Alexander Monakov
2022-12-23 17:45               ` Jose E. Marchesi
2022-12-23 19:21               ` Qing Zhao
2022-12-23 19:36                 ` Alexander Monakov
2022-12-23 19:57                   ` Qing Zhao
2022-12-24  8:10                     ` Alexander Monakov
2022-12-24  9:26                       ` Richard Biener
2022-12-24  9:58                         ` Jose E. Marchesi
2022-12-24 10:06                           ` Richard Biener
2022-12-24 10:18                           ` Alexander Monakov
2022-12-26  0:29                           ` Segher Boessenkool
2023-01-05 18:11                       ` Qing Zhao
2022-12-23 10:05   ` Richard Sandiford
2022-12-23 10:42     ` Jose E. Marchesi
2023-01-13 18:20       ` [PATCH] sched-deps: do not schedule pseudos across calls [PR108117] Alexander Monakov
2023-01-13 18:23         ` Richard Sandiford
2023-01-13 18:33         ` Jose E. Marchesi

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=f41bb491-fd14-801e-ed78-797a1408dffa@ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jose.marchesi@oracle.com \
    --cc=qing.zhao@oracle.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).