[patch][rfc] make tree PRE code-size aware

[Richard Guenther]

On Wed, 3 Dec 2008, Steven Bosscher wrote:

> Hi,
> 
> Running PRE usually increases code size.  PRE eliminates partially
> redundant computations by making them fully redundant. This is
> achieved by inserting expressions on the edges where the result of the
> computation is not available. Often, more than one expression is
> inserted to make just one expression fully redundant. The result is
> code size increase.
> 
> The attached patch teaches tree-ssa-pre.c that inserting expressions
> on more than one edge probably will increase code size.
> 
> This is quite effective. I have tested this with CSiBE on
> mips-unknown-elf with three configurations: unpatched -Os, -Os with
> PRE enabled (but without this patch), and -Os with PRE enabled and the
> attached patch applied.  The best result is still unpatched -Os.
> Unpatched -Os+PRE gives a huge code size increase (almost 17%).
> Patched -Os+PRE gives a code size increase of less than 0.2%.  I've
> not bothered to investigate, and just decided to keep PRE disabled by
> default at -Os. But people may want to toy with disabling/enabling PRE
> for their favorite code-size dependent project, because there are a
> few cases where PRE actually reduced code size a bit (especially with
> another patch I have, to add hoisting to tree-ssa-pre).
> 
> Bootstrapped&tested (with PRE enabled at -Os) on ia64-linux-gnu and
> x86_64-linux-gnu. Built, regtested, and CSiBE-tested on
> mips-unknown-elf.
> 
> The patch may also be interested for targets with few registers,
> because inserting less usually also results in less or no increase in
> register pressure. Richi, it would be interesting to see what this
> does for x86 benchmarks, if you add a check for SMALL_REGISTER_CLASSES
> at the insert-or-not decision point. In the past, we had multiple bug
> reports about PRE wrecking x86 code due to increased register
> pressure.
> 
> What do you folks think of this patch?

I think it's reasonable.

+                 /* If the available value is not a NAME, PREing this
+                    value will probably result in a copy on the edge
+                    to assign the expression to a register.  */
+                 if (edoubleprime->kind != NAME)
+                   inserts_needed++;

Any reason to not handle constants the same as NAME?  I'll throw the
patch on vangelis.

Thanks,
Richard.