This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Deadly optimization bug (all gcc versions!)
- To: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Subject: Re: Deadly optimization bug (all gcc versions!)
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 18 Oct 1999 00:57:30 -0600
- cc: Bernd Schmidt <bernds at cygnus dot co dot uk>, Joern Rennecke <amylaar at cygnus dot co dot uk>, dje at watson dot ibm dot com, veksler at il dot ibm dot com, egcs at egcs dot cygnus dot com, kenner at vlsi1 dot ultra dot nyu dot edu
- Reply-To: law at cygnus dot com
In message <4.2.0.58.19990830110013.05c9e3a0@mail.lauterbach.com>you write:
> At 10:37 30.08.99 , Jeffrey A Law wrote:
>
> > In message <4.2.0.58.19990830094306.047fd8c0@mail.lauterbach.com>you wr
> ite:
> > > At 16:14 24.08.99 , Bernd Schmidt wrote:
> > > >+ /* We can't do anything if the value is set in between the
> > insns we
> > > are
> > > >+ processing. */
> > > >+ if (INSN_CUID (reg_last_set[regno]) <= INSN_CUID (subst_insn)
> )
> > > >+ return 0;
> > > >+
> > >
> > > Just for my understanding, reg_last_set[regno] will not point past
> > > subst_insn here? What I'm thinking about is, what happens if we have
> > 3 SETs
> > >
> > > like:
> > >
> > > SET1
> > > start_of_subst_tree
> > > ...
> > > SET2
> > > ...
> > > subst_insn
> > > ...
> > > SET3
> > >
> > > Will reg_last_set[] point to SET2 or SET3? If it points to SET3, your
>
> > patch
> > > doesn't cover all possibilities, or?
> >I don't think reg_last_set can point to set3 since we haven't processed
> >anything beyond subst_insn yet.
> >
> >It can point to SET2, which is the case Bernd's patch is dealing with.
>
> Ah, ok. Thanks for the clarification. I was under the impression all this
> reg_* arrays were computed at the start of combine for the whole function
> and then updated on-the-fly during combine.
You are right in that we do initialize those arrays just after combine
starts to aid in computing a variety of values (like the nonzero_bits and
num_sign_bit_copies).
But we zero reg_last_set before we actually start trying to combine
instructions via a call to init_reg_last_arrays, then we start building them
again -- we record values for each insn as it is processed in the main
combiner loop. We can also record a value as we make successful combinations.
What makes it possible for reg_last_set to point to SET2 in the example
above is we have already processed SET2 in the main combiner loop.
The way combine works is to take an insn (call it I3 or subst_insn). combine
looks at the LOG_LINKS of I3, which will point to *earlier* insns which
compute values that are used by I3. That is how we can get a case where
subst_low_cuid points before SET2 while we trying to do a combination into
I3 which is after SET2.
jeff