This is the mail archive of the 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: reg_scan info validity during jump

  In message <>you write:
  > Am Fri, 10 Jul 1998 schrieb David S. Miller:
  > >I was tooling around with some sparc backend optimizations, decided to
  > >fiddle with BRANCH_COST, and found the following set of problems as a
  > >result.
  > >
  > >duplicate_loop_exit_test depends upon having valid reg_scan info
  > >around for several reasons, most importantly:
  > >
  > >1) regno_first_uid must be valid
  > >2) regno_last_uid must be valid
  > >3) max_reg_num() must return the same value it did when
  > >   reg_scan() was most recently run
Agreed.  I went back and looked at the old version of duplicate_loop_exit_test
and it has the same problems.  Presumably the more aggressive code has
just uncovered the latent bug.

  > >My fear is that if this isn't crashing existing configurations in the
  > >current developer sources, it is causing optimization opportunities to
  > >be lost.  Much of the time, one is lucky because the allocation of
  > >reg_n_info grabs some "slop" extra entries.  I think this is bad
  > >programming practice and it should be allocating more strictly, and
  > >instead we should fix the core problems.
I think the "slop" entries are so we can grow the tables inexpensively.
Maybe Meissner could comment on this.

Anyway I think the better patch is to simply not copy the loop exit
code if it references a register higher than max_reg_num.  Yes we
miss some opts, but calling reg_scan like that is very heavyweight.

Longer term we'll want to use the valarray stuff to grow the table
as we create new regs :-)


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