This is the mail archive of the
mailing list for the GCC project.
Re: reg_scan info validity during jump
- To: "David S. Miller" <davem at dm dot cobaltmicro dot com>
- Subject: Re: reg_scan info validity during jump
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sat, 11 Jul 1998 01:13:03 -0600
- Cc: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>, rth at cygnus dot com, meissner at cygnus dot com, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <email@example.com>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
> >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 :-)