Re: pipeline description

[Alex Turjan <aturjan at yahoo dot com>]

Alexander is right. Perhaps you can implement the TARGET_SCHED_ADJUST_COST
, then catch in the debugger the two instructions that you expect to be 
scheduled together and see what the default latency is or if needed you 
may just adjust it to the proper value.

Alex


--- On Fri, 11/12/10, Alexander Monakov <amonakov@ispras.ru> wrote:

> From: Alexander Monakov <amonakov@ispras.ru>
> Subject: Re: pipeline description
> To: "Ian Lance Taylor" <iant@google.com>
> Cc: "roy rosen" <roy.1rosen@gmail.com>, gcc@gcc.gnu.org
> Date: Friday, November 12, 2010, 1:22 PM
> 
> 
> On Thu, 11 Nov 2010, Ian Lance Taylor wrote:
> 
> > roy rosen <roy.1rosen@gmail.com>
> writes:
> > 
> > > If I have two insns:
> > > r2 = r3
> > > r3 = r4
> > > It seems to me that the dependency analysis
> creates a dependency
> > > between the two and prevent parallelization.
> Although there is a
> > > dependency (because of r3) I want GCC to
> parallelize them together.
> > > Since if the insns are processed together the old
> value of r3 is used
> > > for the first insn before it is written by the
> second insn.
> > > How do I let GCC know about these things (When
> exactly each operand is
> > > used and when it is written)?
> > > Is it in these hooks?
> > > In which port can I see a good example for that?
> > 
> > I was under the impression that an anti-dependence in
> the same cycle was
> > permitted to execute.? But perhaps I am
> mistaken.
> 
> No, you are right.? That is the norm when compiling
> for ia64, for example.? I
> don't think the backend should specifically care about it:
> the anti-dependency
> gets zero latency, and the scheduler is able to issue the
> second instruction
> on the same cycle after issuing the first.
> 
> Alexander
>