This is the mail archive of the gcc@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]

Re: Deadly optimization bug (all gcc versions!)


  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


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