compiling very large functions.

Daniel Berlin dberlin@dberlin.org
Sun Nov 5 20:01:00 GMT 2006


On 11/5/06, Eric Botcazou <ebotcazou@adacore.com> wrote:
> > AFAIK not one of the tree optimizers disables itself, but perhaps we
> > should. The obvious candidates would be the ones that require
> > recomputation of alias analysis, and the ones that don't update SSA
> > info on the fly (i.e. require update_ssa, which is a horrible compile
> > time hog).
>
> Tree alias analysis can partially disable itself though:

No, it can't.  Tree alias representation can :)

it is also not really partially disabling. It's really fully disabling
in 99% of

>
>   /* If the program has too many call-clobbered variables and/or function
>      calls, create .GLOBAL_VAR and use it to model call-clobbering
>      semantics at call sites.  This reduces the number of virtual operands
>      considerably, improving compile times at the expense of lost
>      aliasing precision.  */
>   maybe_create_global_var (ai);
>
> We have found this to be quite helpful on gigantic elaboration procedures
> generated for Ada packages instantiating gazillions of generics.  We have
> actually lowered the threshold locally.

As i alluded to above, this is disabling representation of accurate
call clobbering. It still performs the same analysis, it's just not
representing the results the same way.

(This is also another one of those things that makes other places
pretty hairy as a result)

This is in fact, a side-effect of the fact that we currently try to
represent aliasing information in terms of "variables things access"
instead of just saying "we know these things can touch the same part
of the heap".

IE we should be making memory equivalence classes and using those as
the symbols, instead of variables.  Otherwise, we end up saying "these
things can touch the same 30 variables" by listing all 30 variables in
vops, instead of just creating a single symbol that represents 30
variables and using this.

(Finding a good set of equivalence classes to use is, of course, a
Hard Problem(TM) , which is why we started by doing it this way).



More information about the Gcc mailing list