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