Re: SH4 SFmode move latency problem?

[Vladimir Makarov <vmakarov at redhat dot com>]

tm wrote:
> 
> On Mon, 11 Nov 2002, Joern Rennecke wrote:
> 
> > tm wrote:
> > >
> > > On Mon, 11 Nov 2002, Joern Rennecke wrote:
> > >
> > > > tm wrote:
> > > > > This is from CVS head.
> > > >
> > > > Then indeed a zero latency is specified for sh4 (using ls_group).
> > > >
> > > > Can you provide a test case?
> > >
> > > It's layer3.i from stress-1.17 compiled with -O2 -m4 -ml.
> > >
> > > I will send it in a separate message.
> >
> > [This is using pipe_model "sh4"]
> >
> > Indeed, it appears that the code is pessimized by this schedule.
> > We want to issue the first double precision multiply (muldi_i, type
> > dfp_arith in sh.md) as soon as possible, because it blocks the FPU
> > "F2" unit for the following multiplies for six cycles (starting in
> > cycle 3).
> > However, the 2 loads that feed the second multiply are scheduled
> > first, even though we need them to start just one cycle before the
> > second multiply (so that we can use the load_store slot of that
> > cycle in addition to the one simultanous to the issue of the second
> > multiply).
> >
> > The comments in the scheduler seem to suggest that the problem is the
> > heuristic to perfer the longest dependency chain, which does not take
> > function unit conflicts into account.
> > I tried to define TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD to
> > a function that returns 8, and later even 160, and removed *sched*.o
> > before rebuilding, but to no avail; the generated assembler is still
> > identical.
> >
> > I don't think I can use any of the TARGET_SCHED_REORDER* macros,
> > since they don't have a documented interface to do look ahead.
> 
> Hey Vladimir, have you gotten a chance to look at this problem?
> 
> Do you need a copy of the testcase to replicate the problem?

  Sorry, I've missed Joern's mail.  The current scheduler even with
lookahead can not solve the problem.  The first cycle multipass
scheduling examines only the current cycle (and the ready queue).  In
general the scheduler has no infrastructure to look at the future
instruction issues or to return to the past and try another schedule. 
Optimal scheduling could solve the problem but it is NP task.

  So I see the only heuristic solution is to use a hook to reorder the
ready queue,  The hook should look at the depended instructions.  But
you should be accurate because the hook might worse code in other cases.

Vlad