Re: AIX regression due to DFA scheduler merge

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 19:05 03.06.2002, Vladimir Makarov wrote:
> "Vladimir N. Makarov" wrote:
> >
> > David Edelsohn wrote:
> >
> > >
> > > With the libcall patch, insn 2951 (plus:SI) is scheduled before insn 1711
> > > and insn 1715 on which it has anti-dependence.  Without the libcall 
> patch,
> > > it is scheduled after those instructions where reg:SI 791 is used.
> > >
> > >         I would really appreciate some help debugging why the instruction
> > > is being moved across the dependency.  I will be happy to send
> > > pre-processed input and any RTL dumps people want to browse.
> >
> >   You can send it to me.  I'll look at this tomorrow.  And please, some 
> instructions how to reproduce it.  The scheduler uses
> > forward dependencies in its work.  RTL contains only backward 
> dependencies.  To get forward dependencies, please use
> > -fsched-verbose=5.
> >
> >   I have suspicion that there is some conflict in setting SCHED_GROUP_P 
> for libcalls (your patch) and calls (it is present in
> > sources long ago) because calls can be inside libcalls.
>
>   The first of all your patch sets up SCHED_GROUP_P for libcalls after
> the building backward dependencies.  The backward dependencies should be
> set up onto the last insn in the group see the following code in
> add_dependecies:
>
>   /* If elem is part of a sequence that must be scheduled together, then
>      make the dependence point to the last insn of the sequence.
>      When HAVE_cc0, it is possible for NOTEs to exist between users and
>      setters of the condition codes, so we must skip past notes here.
>      Otherwise, NOTEs are impossible here.  */
>   next = next_nonnote_insn (elem);
>   if (next && SCHED_GROUP_P (next)
>       && GET_CODE (next) != CODE_LABEL)
>     {
>       /* Notes will never intervene here though, so don't bother
> checking
>          for them.  */
>       /* Hah!  Wrong.  */
>       /* We must reject CODE_LABELs, so that we don't get confused by
> one
>          that has LABEL_PRESERVE_P set, which is represented by the same
>          bit in the rtl as SCHED_GROUP_P.  A CODE_LABEL can never be
>          SCHED_GROUP_P.  */
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Doesn't that mean that the RTL flag checking for SCHED_GROUP_P wrongly 
includes CODE_LABEL?

Franz.