On Fri, Jan 27, 2017 at 1:27 AM, Andrew Pinski <pins...@gmail.com> wrote: > 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.
Either that or you add another hook to the backend to get these insn codes which is also fragile ? If you do proceed with 8 as your magic number then let backends override it. Magic numbers in target independent code irrespective of whether they are 8 or 3 annoy me :) regards Ramana > > Thanks, > Andrew > >> >> >> Segher
