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

Segher Boessenkool segher@kernel.crashing.org
Fri Jan 27 14:37:00 GMT 2017


On Fri, Jan 27, 2017 at 02:30:49PM +0100, Richard Biener wrote:
> >> Ok, maybe with -fno-trapping-math we don't consider that case but even
> >> then generating
> >> a NaN is usually dreadfully slow so avoiding speculation of such insns
> >> looks good in
> >> any case (w/o considering its cost).
> >
> > And -ffast-math includes -ffinite-math-only.  No, the testcase never
> > takes the square root of number smaller than zero, it isn't *that* slow ;-)
> 
> Well, the testcase as written doesn't but if you speculate the sqrt it might?

Yeah true.  Except we have -ffast-math so we told the compiler that is
just fine to do.

> > Things slow down so much because there is a loop immediately followed
> > by a square root insn, and sched-rgn decides it is a good idea to move
> > it to inside the loop.  Which is a bad idea no matter what the frequency
> > of the loop is because 1) we do not get such profiles very correct, and
> > 2) sqrt is really expensive.
> 
> I understood that but then moving sth inside a loop is almost never a win.

It defaults to moving something if it has space for it in the schedule
and it is executed at least 40% of the time (I think).

> Can't "not modeled" insns not be marked somehow in the pipeline description?

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.


Segher



More information about the Gcc-patches mailing list