On 01/27/2017 03:01 PM, Segher Boessenkool wrote:
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.
No strong opinions on the two approaches. I could easily see defining a
hook and ports implementing the hook via attributes if that were easier
for them. Other ports might implement the hook by scanning the insn for
key RTL codes.
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.
No -- ports handle this inside there eligible_for_delay_XXX support.
It's not something that could be reasonably re-used within the scheduler.
Jeff
