This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: AIX regression due to DFA scheduler merge
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: law at redhat dot com,David Edelsohn <dje at watson dot ibm dot com>,gcc-patches at gcc dot gnu dot org,Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 03 Jun 2002 20:23:05 +0200
- Subject: Re: AIX regression due to DFA scheduler merge
- References: <Your message of Mon, 03 Jun 2002 19:28:34 +0200. <5.1.1.2.2.20020603192655.03fb6e50@mail.lauterbach.com><5.1.1.2.2.20020603195509.03fb6e50@mail.lauterbach.com>
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.