IPA merge part 1: localize SSA variables

[Diego Novillo]

Jan Hubicka wrote on 10/21/06 15:42:

> I took same path as with localizing CFG some time ago by adding cfun->ssa
> structure and using accestor macros.  This avoids need to rewrite all
> apperances of the variables in the sources. At time of merging CFG we discussed
> plan to replace those by direct references to cfun->cfg structure.  This part
> of plan sadly never matherialized, I sent patch replacing
> ENTRY_BLOCK/EXIT_BLOCK, but there didn't seem to be good time for fitting it in
> (it is painful for open branches).  I can update that one too and proceed with
> other cfun->cfg/cfun->ssa fields in incremental patches.
> 
Well, I think it must be done now.  We will always have active
branches and if we keep using this excuse, the Right Thing will never
get done.

> Where the polution of namespace would be really anoying, like for aliasing
> info, I already took path of using direct references.  Also note that the patch
>
No, let's please use the accessors qualified by CFUN.  That is,

s/cfun->ssa->blah/blah (cfun)/

> ! struct ssa GTY(()) {
>
I would prefer to call this 'df' or 'dataflow'.  The term SSA is more
specific and this structure contains information about dataflow in
general.

> ! #define referenced_vars cfun->ssa->x_referenced_vars
> ! #define ssa_names cfun->ssa->x_ssa_names
> ! #define modified_noreturn_calls cfun->ssa->x_modified_noreturn_calls
> ! #define global_var cfun->ssa->x_global_var
> ! #define nonlocal_all cfun->ssa->x_nonlocal_all
> ! #define aliases_computed_p cfun->ssa->x_aliases_computed_p
> ! #define in_ssa_p (cfun->ssa && cfun->ssa->x_in_ssa_p)
> ! 
I don't think I like this.  When doing IPA, we will likely want to
access different things at the same time.  I like the idea of
accessors, but I would prefer them to have 'cfun' as an argument:

#define referenced_vars(FN)	FN->ssa->x_referenced_vars

I think there is a practical limit about how much we can worry about
other active branches.  This usage of referenced_vars, ssa_names, etc
without specifying the CFUN you are referring to is a bit troublesome.
I have been bitten by it when doing the OMP expansion code.  It's easy
to use the traditional non-parameterized names and get burnt when
operating in IPA mode.

I would much rather we just switch to parameterize all these
identifiers with CFUN.  And I mean ALL of them.


> ! /* FIXME: Little rewrite of tree-ssa-operands could probably make those shared
> !    across all functions avoiding need to privatize them.  Envolving
> !    tree-ssa-operands implementation however makes this step bit impractircal.
                                                                    ^^^^^^^^^^^^
								    impractical
> !    */
> ! #define free_defs (cfun->ssa->x_free_defs)
> ! #define free_uses (cfun->ssa->x_free_uses)
> ! #define free_vuses (cfun->ssa->x_free_vuses)
> ! #define free_maydefs (cfun->ssa->x_free_maydefs)
> ! #define free_mustdefs (cfun->ssa->x_free_mustdefs)
> ! #define free_ssanames (cfun->ssa->x_free_ssanames)
> ! #define operand_memory (cfun->ssa->x_operand_memory)
> ! #define operand_memory_index (cfun->ssa->x_operand_memory_index)
>   
Likewise here.  Why is it that you need to privatize these caches?  I
don't think I followed your reasoning.