Re: [1/2] Rename across ebbs

[Richard Sandiford <richard.sandiford@linaro.org>]

Bernd Schmidt <bernds@codesourcery.com> writes:
> 	* regrename.c (struct du_head): Remove member terminated.
> 	(create_new_chain): Don't initialize it.
> 	(scan_rtx_reg): Don't set or test it, test the open_chains_set
> 	bitmap instead.
> 	(tick, this_tick): New global variables, moved out of
> 	regrename_optimize.
> 	(current_id, open_chains, closed_chains, open_chains_set,
> 	live_in_chains, live_hard_regs): Reorder declarations.
> 	(dump_def_use_chain): Move function earlier in the file.
> 	(rename_chains): New static function, broken out of
> 	regrename_optimize.
> 	(regrename_optimize): Use it.  Remove #if 0'ed code.

The reindent operation seems to have introduced some weird formatting
(due in some cases to the existing code not really following the rules).
So:

> +/* Process the closed chains starting with ALL_CHAINS and rename
> +   registers if possible.  */
> +static void
> +rename_chains (du_head_p all_chains)
> +{
> +  HARD_REG_SET unavailable;
> +
> +

excess whitespace here.

> +      /* Iterate over elements in the chain in order to:
> +	 1. Count number of uses, and narrow the set of registers we can
> +	 use for renaming.
> +	 2. Compute the superunion of register classes in this chain.  */

original formatting was better:

      /* Iterate over elements in the chain in order to:
	 1. Count number of uses, and narrow the set of registers we can
	    use for renaming.
	 2. Compute the superunion of register classes in this chain.  */

> +	      if (has_preferred_class
> +		  && (pass == 0)
> +		  != TEST_HARD_REG_BIT
> +		  (reg_class_contents[preferred_class], new_reg))
> +		continue;

The last two lines of the condition aren't indented properly.
(I checked it wasn't just a diff artefact.)

> +		  && ((pass == 0
> +		       && !TEST_HARD_REG_BIT
> +		       (reg_class_contents[preferred_class],
> +			best_new_reg))
> +		      || tick[best_new_reg] > tick[new_reg]))

Same thing with the TEST_HARD_REG_BIT argument here.

OK otherwise, thanks.  I suppose removing the terminated field is a
(very) slight compile-time pessimisation in itself.  We only set it
when we were modifying the chain anyway, so there should be no cache
pollution problems.  And calling bitmap_bit_p is more expensive than
a bitfield test on a structure that we're already looking at.

The difference is nothing like enough to be a problem though, especially
if it makes the other patch easier.  Just saying in case anyone thought
it wasn't being considered...

Richard