This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [LTO] Localize SSA variables

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]