AIX regression due to DFA scheduler merge

law@redhat.com law@redhat.com
Mon Jun 3 10:46:00 GMT 2002


In message <5.1.1.2.2.20020603192655.03fb6e50@mail.lauterbach.com>, Franz Sirl 
writes:
 > 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 1
 > 711
 > > > > 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 instruct
 > ion
 > > > > 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?
It certainly seems wrong to me to have a CODE_LABEL within a scheduling group 
--
think about it, a CODE_LABEL will start a new basic block and we shouldn't
have a scheduling group that crosses multiple blocks.

jeff



More information about the Gcc-patches mailing list