This is the mail archive of the
mailing list for the GCC project.
Re: IPA merge part 1: localize SSA variables
- From: Jan Hubicka <jh at suse dot cz>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 15 Nov 2006 17:54:05 +0100
- Subject: Re: IPA merge part 1: localize SSA variables
- References: <20061021194201.GI29675@kam.mff.cuni.cz> <455B3768.firstname.lastname@example.org>
> >! #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.
OK, I can rename the current "ssa" struct to "df" and do the grand
substitution (ie write a script, catch formatting problems) and produce
patch. For me "dataflow" is the general idea, while "ssa" is what our
representation use, but I don't have problem with df name.
The rationale behind all the above macros was primarily to keep
amount of noise down as once those substitutions are done, tracking
mainline is quite impractical, so this was definitly not an option for
the branch that was open for quite some time.
I also do agree that the substitutions shall be done and probably
gradually we ought to add cfun argument to many of our APIs instead of
relying on the cfun global.
Do we preffer the macro way that is somewhat unfriendly to preprocessor,
rather than direct cfun->df->xxx accestors or inline functions with set
variants like we have for many df fields?
> >! /* FIXME: Little rewrite of tree-ssa-operands could probably make those
> >! across all functions avoiding need to privatize them. Envolving
> >! tree-ssa-operands implementation however makes this step bit
> >! */
> >! #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.
There was problems with the operand cache freeing and changing the
context in twisted way. I can probably split this up, do grand
substitution up to operand caches first and deal with operand caches in
subsequent patch. Once I did shared caches on the IPA branch, but the
subsequent changes to the mainline into tree-ssa-operands forced me to
revert that part, this should not be problem after merge, of course. But
it definitly needs some not completely obvious changes.
If this sounds like a plan, I will merge from mainline to IPA branch, do
the substitution. OK? (I am asking as I would like to get the patch in
quite quickly then to not have too many rejects as probably about any
touched file will offend.
Thanks for looking into this!