From: Segher Boessenkool <segher@kernel.crashing.org>
To: Jeff Law <law@redhat.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [RFC] sched: Do not move expensive insns speculatively (PR68664)
Date: Fri, 27 Jan 2017 22:04:00 -0000 [thread overview]
Message-ID: <20170127220154.GJ30284@gate.crashing.org> (raw)
In-Reply-To: <b29d3b71-6b2b-5708-51ca-ead89c9f7188@redhat.com>
On Fri, Jan 27, 2017 at 11:04:42AM -0700, Jeff Law wrote:
> >Well, the only thing from the pipeline description that is used here is
> >the insn latency, which isn't all that much higher than "normal" FP insns.
> >And simply "not decribed properly" won't do much good -- if we could
> >(without blowing up the automata) we would, and sched-rgn would then
> >still speculate this.
> And I think this is the core of the issue. We have multiple ports that
> don't necessarily fully describe the latency, issue rates, etc of
> certain insns like div/sqrt/rsqrt. There are good reasons for doing that.
>
> Because of the partial description, the scheduler may think those insns
> fit into a pipeline bubble within the loop, when reality they do not.
>
> The scheduler currently has no way of knowing what insns have this
> property. While there are cases where we'd like to speculate a div or
> sqrt to give it more time to complete without stalls -- there's no good
> way to do that without fully describing them to the scheduler.
>
> My preference would be somehow either mark those insns as not fully
> modeled and avoid speculating on them. Or invent a target hook to allow
> the scheduler to query the backend.
This is my preference -- have it in one location, not spread out over
many instruction patterns, or many scheduling descriptions.
> Note that these could be used elsewhere -- for example delay slot
> scheduling and predication. Delay slot scheduling does speculation and
> there's ports that simply refuse to allow certain instructions (div/sqrt
> on one port, I think all FP stuff on another) to avoid these kinds of
> problems.
Are you saying there already is a hook we could use, maybe after
adjusting it a bit? That would be ideal.
> Similarly nullification/predication often work by wiping out the final
> posting of results into the register file. So imagine a non-pipelined
> div/sqrt. Predicating a div/sqrt instruction will actually keep the
> pipeline busy computing results that will be thrown away and preventing
> other useful work from occurring. And, yes, this really does happen.
> THe PA suffered from these problems.
Segher
next prev parent reply other threads:[~2017-01-27 22:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 0:40 Segher Boessenkool
2017-01-27 1:12 ` Andrew Pinski
2017-01-27 1:27 ` Segher Boessenkool
2017-01-27 2:12 ` Andrew Pinski
2017-01-27 11:36 ` Ramana Radhakrishnan
2017-01-27 12:43 ` Segher Boessenkool
2017-01-27 18:11 ` Jeff Law
2017-01-27 12:45 ` Bernd Schmidt
2017-01-27 14:19 ` Segher Boessenkool
2017-01-27 18:20 ` Jeff Law
2017-01-27 12:20 ` Richard Biener
2017-01-27 12:42 ` Segher Boessenkool
2017-01-27 13:43 ` Richard Biener
2017-01-27 14:37 ` Segher Boessenkool
2017-01-27 18:08 ` Jeff Law
2017-01-27 22:04 ` Segher Boessenkool [this message]
2017-01-27 22:21 ` Jeff Law
2017-01-27 22:30 ` Segher Boessenkool
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=20170127220154.GJ30284@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=law@redhat.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).