This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] P6 microarch (Pentium 2/3) DFA scheduler description
- From: Steven Bosscher <stevenb at suse dot de>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, jh at suse dot cz, law at redhat dot com,vmakarov at redhat dot com
- Date: Thu, 26 Feb 2004 11:51:11 +0100
- Subject: Re: [RFC] P6 microarch (Pentium 2/3) DFA scheduler description
- Organization: SUSE Labs
- References: <firstname.lastname@example.org> <20040226104217.GK21236@kam.mff.cuni.cz>
On Thursday 26 February 2004 11:42, Jan Hubicka wrote:
> > Hello,
> just few quick comments:
> ! ;; The goal is to schedule suck that we have few-one-one uops sequences
> ! ;; in each cycle to decode as many instructions per cycle as possible.
> ! (define_cpu_unit "decoder0" "ppro_decoder")
> ! (define_cpu_unit "decoder1" "ppro_decoder")
> ! (define_cpu_unit "decoder2" "ppro_decoder")
> ! ;; All simple instructions can be decoded on each of the three decoders.
> ! (define_reservation "decodern" "(decoder0|decoder1|decoder2)")
> I think you need exclusion/presecne sets here in order to ensure that
> decoder1 is not allocated before decoder0 (they are always fed in order)
> But for deterministic automaton this perhaps don't matter, don't know
> for sure.
You are right, and it does matter. I had hard-coded this kind of
re-ordering in i386.c and it helped a bit but not enough to justify
such ugly code. I was wondering how I could force the DFA to first
feed decoder0, and you've just provided me with a possible answer.
> You need to model that operands needed for memory are needed earlier
> than operand needed just for computation. (...) I think you need to
> increase the latencies by one cycle for operations loading from memory.
Okey, I'll experiment with that.