This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 01/27/2017 04:32 AM, Ramana Radhakrishnan wrote:
On Fri, Jan 27, 2017 at 1:27 AM, Andrew Pinski <pinskia@gmail.com> wrote:
On Thu, Jan 26, 2017 at 5:19 PM, Segher Boessenkool
<segher@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
<segher@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 :)
Magic numbers are definitely not the way to go here :-)

Consider a port where a particular commonly used insn blocks anything else from executing in the CPU or FPU for several cycles. Given there's literally no way to avoid the lock, we don't bother modeling that insn for the purposes of scheduling. We just claim single cycle latency and issue rate.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]