On Fri, Jan 27, 2017 at 11:32:32AM +0000, Ramana Radhakrishnan wrote: > >>> 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 ?
How so? The hook would get the full insn pattern of course. > 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 :) If we abuse insn_rtx_cost for this then every target will need to tune the cutoff, and there may not even be a good cutoff value at all. It also in the PowerPC case means we need to adjust our costs (sqrt does not have any defined cost right now, we never needed it). IMO it's much cleaner to have a nice hook that says exactly what it does in its name, say, targetm.sched.do_not_speculate_insn or such. Segher
