This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [LTO] Localize SSA variables
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, gnovillo at redhat dot com, rth at redhat dot com
- Date: Sun, 11 Jun 2006 09:24:13 -0400
- Subject: Re: [LTO] Localize SSA variables
- References: <20060611124054.GL15354@kam.mff.cuni.cz>
Jan Hubicka wrote:
> Hi,
> as discussed briefly with Diego and Kenneth on IRC, I would like to
> break out the basic changes needed to make IPA on SSA happen from the
> IPA branch and send them for consideration for merging to LTO branch.
>
> In general I believe that we do want to perform IPA optimization on SSA
> (not necesarily have the on-disc representation in SSA however) and that
> the change is better to be done earlier, since it affects datastructure
> decisions quite closely (ie all datastructures needs to be designed in a
> way allowing multiple functions in SSA form, that is dificult for
> example with current variable annotations and memory consumption of
> basic SSA form is also more of a concern), so I think it is profitable
> to merge the changes. However it can be done now or later on depending
> on the overall plan to work on LTO. I am mostly sending the patch for
> consideration and comments.
>
> If merging early seems good idea, I would like to proceed by incremental
> patches pretty much as in a way I would like to send them in stage1 of
> 4.3. There are number of details to discuss with people interestedin
> SSA/gimple datastructures si hopefully this will also increase chances
> to merge all relevant parts from IPA branch to mainline soon.
>
> Overall mege plan would be to first localize the variables in current
> step, in next step add the infrastructure allowing to turn multiple
> functions into SSA (and don't do inlining), third part would be the
> inliner itself.
>
> I did some testing on IPA branch for GCC summit paper and to my surprise
> the memory costs for turning everything into SSA early is pretty low and
> is mostly made neutral by ability to optimize early and improve
> effectivity of inlining. There are few regressions caused by inliner
> not being able to properly update SSA form after inlining functions that
> after being inlined throw local exceptions. I have rather intrusive fix
> for this that I would like to avoid, so I would like to discuss this
> details later during merging progress. Otherwise things seems to be
> quite stable.
>
> Weak side of this patch is the fact that it localizes some variables
> that can be shared across bodies with little rewriting of the underlying
> datastructures (such as freelist and so). Those are probably best
> addressed by incremental patches I can send as followup, but of course
> can do it in the patch as well or wait for some bigger reorganization of
> SSA we will need to do in foreseeable future anyway.
> Other weak side is that is uses the macros to access cfun->ssa fields
> that are frequent in GCC sources to avoid merge headaches. I used same
> scheme for CFG branch and promised to clean it up later and still plan
> to do so. There is partial patch for this in the queue, but probably
> late stage1 or mid stage2 is best to avoid branch syncronization issues.
>
> Does this seem to make sense?
>
>
I was going to discuss this with diego on friday and he ended up with
child duty.
If it is ok with diego and mark it is ok with me.
kenny