This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Incorrect DFA scheduling of output dependency.
On Dec 07, 2004 02:01 PM, Steven Bosscher <stevenb@suse.de> wrote:
> On Dec 07, 2004 11:59 AM, Daniel Towner <daniel.towner@picochip.com> wrote:
>
> > Vlad, et al.,
> >
> > >> I was wrong here. The instruction sequence is actually a data
> > >> (read-after-write) dependency, not an output dependency
> > >> (write-after-write). However, the relevent portion of the scheduler
> > >> dump is as follows:
> > >>
> > >> (note 82 147 64 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> > >>
> > >> (insn:TI 64 82 150 2 (set (reg/v:HI 4 R4 [orig:25 rdIndex ] [25])
> > >> (const_int 0 [0x0])) 15 {movhi} (nil)
> > >> (nil))
> > >>
> > >> (note 150 64 133 2 NOTE_INSN_LOOP_END)
> > >>
> > >> (insn 133 150 135 2 (set (reg:HI 5 R5 [33])
> > >> (ashift:HI (reg/v:HI 4 R4 [orig:25 rdIndex ] [25])
> > >> (const_int 2 [0x2]))) 48 {ashlhi3} (insn_list:REG_DEP_ANTI
> > >> 64 (nil))
> > >> (expr_list:REG_EQUAL (ashift:HI (reg/v:HI 4 R4 [orig:25 rdIndex ]
> > >> [25])
> > >> (const_int 2 [0x2]))
> > >> (nil)))
> > >>
> > >> Does this state that insn 133 is anti-dependent on insn 64?
> > >
> > I've discovered that the anti-dependency is inserted by sched_analyze.
> > It occurs because of the NOTE_INSN_LOOP_END between the two instructions
> > above. This note introduces a move barrier between the instructions,
> > which is intended to prevent the two instructions being reordered.
>
>
> Can someone explain please why we have loop notes in the middle of
> a basic block?
In fact maybe someone with a lot of RTL-fu should explain what this
comment in sched-deps is supposed to mean to begin with:
/* If there is a {LOOP,EHREGION}_{BEG,END} insn note in the middle of a basic
block, then we must be sure that no instructions are scheduled across it.
Otherwise, the reg_n_refs info (which depends on loop_depth) would
become incorrect. */
I read this and I had never heard of reg_n_refs before, so:
$ grep -w -r reg_n_refs *
FSFChangeLog.11: * combine.c (try_combine): Clear reg_n_refs if i2dest is not
haifa-sched.c: be correct. Namely: reg_n_refs, reg_n_sets, reg_n_deaths,
sched-deps.c: Otherwise, the reg_n_refs info (which depends on loop_depth) would
So even in the ChangeLogs there is only one reference to reg_n_regs.
Is this bitrot?
Gr.
Steven