IPA merge part 1: localize SSA variables

[Jan Hubicka]

Hi,
> 
> I think in these cases we don't need the read/write accessors, but
> personally I would still like to see the access parameterized, so
> instead of 
> 
>      VEC_quick_push (tree, cfun->gimple_df->ssa_names, NULL_TREE);
>      cfun->gimple_df->free_ssanames = NULL;
> 
> we'd see
> 
>      VEC_quick_push (tree, SSA_NAMES (cfun), NULL_TREE);
>      SSA_NAMES (cfun) = NULL;
> 
> It will save us work in the long run if we ever want to have more than
> one instance around, for whatever reason.

I was considering the macros too, but combining the functional/macro
abstraction didn't seem very consistent (ie we would end up with people
writting macros for the public stuff too)
What precisely do you mean by more than one instance around?
> 
> > In longer run I am not sure how far we want to go with elliminating
> > global cfun accesses.  It definitly do make sense to keep them in local
> > passes - we don't want to add extra argument to every single function in
> > GCC. On the other hand it would be nice from IPA point of view to do,
> > for instance, cfgcleanup directly on specified function after some IP
> > transformation was performed.
> 
> it might make sense to have a local cfun for uses within an
> optimization, especially when that optimization already has a data
> structure which is 'global' within the optimization. So cfun is passed
> to the highest level routine, which initializes the 'local data' for the
> optimization with that value of cfun.  The rest of the optimization
> routine then use that. Any routines shared between different
> optimizations may still need to pass cfun tho. 

Yes, we pretty much can have in each local pass it's static copy of cfun
or just let passmanager for local passes do the job and set the global
variable.
> 
> I do this to some extent in out-of-ssa with its' common data structures.
> a var_map is used by virtually everything, but it is either passed to a
> function, or a more encompassing data structure (like the conflict
> graph)  contains a pointer to the var_map it uses. Then passing the more
> encompassing structure includes all the 'other' values which might be
> needed, such as the relevant var_map. it keeps you from having to pass
> all these extraneous things around, and also makes it clear if there is
> a dependency on a specific instance.  
> 
> (I havent woken up completely yet, so maybe that wasn't really clear
> enough, I don't know :-)
> 
> Bottom line is we don't need to make more work for ourselves, but when
> we are changing these things, we might as well go right to the
> (perceived :-)  end solution for those cases, in my opinion.

Agreed here. I am trying to know where the end sollution is to have some
consistent plan where to move the APIS rather than blindly volunteering
to rename every single variable in GCC this week :)

Honza
> 
> Andrew