[RFC] sched: Do not move expensive insns speculatively (PR68664)

[Segher Boessenkool]

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