Re: RFC -- CSE compile-time stupidity

[Jeffrey A Law <law at redhat dot com>]

On Mon, 2005-02-21 at 16:36 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > Sigh.  I can't wait for this code to become less critical, both in terms
> > of runtime and compile time performance.  There are so many things in 
> > cse.c that are just plain bad....
> > 
> > cse.c has a fair amount of complexity in its hash table management
> > code to avoid spending too much time invalidating/removing items
> > in the hash table when a value of an expression changes.
> > 
> > Specifically we have REG_TICK, REG_IN_TABLE and other fields to track 
> > when entries are valid.  It's fairly common to have code which looks
> > something like this (from mention_regs):
> > 
> > 
> > /* Get the number of times this register has been updated in this
> >    basic block.  */
> > 
> > #define REG_TICK(N) (get_cse_reg_info (N)->reg_tick)
> > 
> > /* Get the point at which REG was recorded in the table.  */
> > 
> > #define REG_IN_TABLE(N) (get_cse_reg_info (N)->reg_in_table)
> > 
> > /* Get the SUBREG set at the last increment to REG_TICK (-1 if not a
> >    SUBREG).  */
> > 
> > #define SUBREG_TICKED(N) (get_cse_reg_info (N)->subreg_ticked)
> 
> I don't see anything wrong with getting rid of these macros, and having 
> the callers do:
> 
>    info = get_cse_reg_info (N);
>    info->tick ... info->reg_in_table ...
That's roughly what I was doing.  The only downside is we'd have to do
a fair amount of code reorganization since we like to use those macros
in nontrivial conditionals.

But I'm having trouble reproducing the speedups now.  Which makes me
wonder if I goof'd the initial conversion or was testing the wrong
binary or something way stupid like that.


Jeff