On Thu, Jan 26, 2017 at 5:19 PM, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > On Thu, Jan 26, 2017 at 05:00:44PM -0800, Andrew Pinski wrote: >> On Thu, Jan 26, 2017 at 4:38 PM, Segher Boessenkool >> <seg...@kernel.crashing.org> wrote: >> > Scheduling should never move very expensive instructions to places they >> > are executed more frequently. This patch fixes that, reducing the >> > execution time of c-ray by over 40% (I tested on a BE Power7 system). >> > >> > Is there some existing way to test for "very expensive insn" or "very >> > expensive insn we should not speculate"? Should there be a new hook? >> > Is only disallowing (FP) SQRT and DIV a good solution? >> >> Seems like it should be checking the insn cost and compare that >> against some parameter. That is possibly set by the target if needed. > > But what is "insn cost"? Latency is no good at all -- we *want* insns > with higher latency to be earlier. fsqrt is not pipelined, and that is > what makes it so costly. (This isn't modeled in the scheduling > description btw: that would make the automata sizes explode, the usual > problem).
I was just talking about RTX cost of the insn. It seems like we don't want to move any insn cost which is high. Even if it is pipelined, it does not make sense to be part of the hot path. Even on in-order targets, we don't want to move instructions which are pipelined either. Say the default is 8 as declared as expensive. Thanks, Andrew > > > Segher
