This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: AIX regression due to DFA scheduler merge


At 20:14 03.06.2002, Vladimir Makarov wrote:
Franz Sirl wrote:
>
> At 19:48 03.06.2002, law@redhat.com wrote:
> >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.
>
> Then the patch below should be added and all casualties fixed.
>

Yes, that is fine. It is nice to have the additional check. Could you
commit it into the main line.
Well, besides the obvious bug Daniel pointed out, this would break bootstrap of all targets I guess and I wouldn't have time to fix anything until tomorrow late evening (CEST +0200 time). It's not that I wouldn't be tempted to commit and leave though, but I try to avoid listening to the bad guy on my shoulder too often... ;-))

Franz.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]