This is the mail archive of the
mailing list for the GCC project.
Re: DFA for PPro, P2, P3
- From: law at redhat dot com
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 03 May 2002 01:19:03 -0600
- Subject: Re: DFA for PPro, P2, P3
- Reply-to: law at redhat dot com
In message <20020502223945.B5496@redhat.com>, Richard Henderson writes:
> On Thu, May 02, 2002 at 08:28:48PM -0600, email@example.com wrote:
> > That's one of the things that is (to me at least) extremely unclear about
> > the PPro/P2/P3 pipeline -- ordering/dependency of uops.
> Well it's quite clear that a load-execute x86 insn (as your example
> must have been)
Actually my example was a shift of a register by a constant. Those
are incorrectly marked as using p0 and p01 in the current pipeline
description. If it was a load-execute it would have used p2 in some
way. I didn't figure it was worth confusing folks with this tidbit
of information :-)
> will consist of a load uop plus an execute uop, and
> it is quite clear that the two must be data dependent.
It's certainly true that some can be derived; it's the obvious thing
to do once the base description is working. Particularly since one of
the strengths of the DFA model is that we can handle/schedule for
resources that are used during different stages of an instruction's
> Now, the execute uop may not be executed immediately after the load
> uop, but I think for all practical purposes on an OOO machine
> reserving the resource is good enough, since that pretty much
> guarantees that at least as many resources as you reserved will
> be available, so it won't run any slower.
> But (p0|p1)+p0 makes no sense no matter how you slice it.
I know. I just haven't gotten around to dealing with dependencies between
the uops yet. Trust me, it's on my todo list.