Re: ideas for modeling pipeline with bypass registers?

[Greg McGary <greg at mcgary dot org>]

"Nitin  Gupta--SSW, Noida" <nitingup@noida.hcltech.com> writes:

> >     source code:
> > 
> >         r1 = r2 + r3;
> >         r4 = r1 + r5;
> >         r6 = r2 + r4;
> > 
> >     timing analysis:
> > 
> >         insn-0: bypass-even <- r2 + r3;
> >         insn-1: bypass-odd <- bypass-even + r5;
> >         insn-2: [ r1 <- bypass-even; bypass-even <- r2 + bypass-odd; ]
> >         insn-3: r4 <- bypass-odd 
> >         insn-4: r6 <- bypass-even

> Can this bypass register be used in allocation?

No.  It doesn't make sense to allocate it because it has a fixed,
limited, machine-defined use and isn't available for other purposes.

> Another point considering
> just your example only is that if this calculated value of r1 is only for
> getting value of r4 then the insn to store bypass register in r1 can
> actually be not needed.  similarly for r4, you can avoid insn-3.

Storing bypass into the register file is automatic, and unavoidable.
Don't confuse the timing analysis with assembler code.  These are not
instructions, but rather descriptions of events.  I should have
labeled them "cycle-N", rather than "insn-N".  Also, I wrote the
example with the assumption that the computation continued long past
this fragment and the destination registers would have lifetimes
beyond the uses shown here.

> Your approach will actually give good results when there are number of ALU
> operations simultaneously and splitting one ALU operation into a bypass
> register at rtl level can actually give insn scheduler chances of allowing
> some other mem load/store insns to be grouped with it.

I assume that by "Your [Greg's] approach", you mean explicitly
modeling bypass registers in RTL.  My gut tells me this is the way to
go, but I haven't worked through the details enough to understand the
problems.

Greg