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
