On Thu, 17 Jul 2025, Filip Kastl wrote:
> On Thu 2025-07-17 11:48:33, Richard Biener wrote:
> > On Thu, 17 Jul 2025, Filip Kastl wrote:
> >
> > > On Thu 2025-07-17 10:00:01, Richard Biener wrote:
> > > > On Thu, 17 Jul 2025, Filip Kastl wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > This patch cuts out the solver from tree-ssa-structalias.cc. Soon,
> > > > > I'd like to
> > > > > also cut out the part that generates constraints and perhaps also
> > > > > other parts.
> > > > >
> > > > > My big goal is to implement Steensgaard-style points-to analysis and
> > > > > use it
> > > > > interprocedurally. Unlike the IPA-PTA we currently have, Steensgaard
> > > > > should be
> > > > > fast enough to be enabled by default. Once this matures a bit, my
> > > > > hope is that
> > > > > this could enable GCC to optimize in many interesting cases where it
> > > > > didn't
> > > > > have enough alias information before. But that is a very long-term
> > > > > vision.
> > > > >
> > > > > Cutting tree-ssa-structalias.cc into smaller files is preparatory
> > > > > work.
> > > > > Even ignoring the upcoming changes, cutting a file of this size into
> > > > > smaller
> > > > > files seems like a good idea to me. I believe it will improve
> > > > > readability.
> > > > > It will also be clearer what I'm modifying in each of the upcoming
> > > > > IPA-PTA
> > > > > patches. For example, I'm not planning to modify the existing solver
> > > > > at all.
> > > > > The splitting will also make it easier to eventually plug in the new
> > > > > Steensgaard solver.
> > > > >
> > > > > I've tried to make as few changes as seemed reasonable. I go into
> > > > > more detail
> > > > > about how I did the splitting in the commit message.
> > > > >
> > > > > I've named the new files *-andersen.{cc,h} because the current solver
> > > > > would be
> > > > > refered to as Andersen-style in points-to analysis literature. When
> > > > > I'll be
> > > > > adding the Steensgard-style solver, I'm planning to call those files
> > > > > *-steens.{cc,h}.
> > > > >
> > > > > Btw, I copied the license comment at the top of
> > > > > tree-ssa-structalias.cc into
> > > > > all the files I created. This means that it says "Copyright (C)
> > > > > 2005-2025" in
> > > > > files which were just created. Is that ok?
> > > > >
> > > > > Bootstrapped and regtested on x86_64. Ok to push?
> > > >
> > > > I'm OK with splitting up the file, but can we get rid of
> > > > 'tree' and 'structalias'? I'd say ssa-pta or for the solver,
> > > > which has nothing to do with SSA, use pta-andersen.{cc,h} instead?
> > > > At least for the new file, don't rename the old one.
> > >
> > > Yes, I'm all for that. I thought about doing that in a later patch but I
> > > guess
> > > it will be nicer to do that now.
> > >
> > > > That extends to the choice of the namespace name as well (I'd use
> > > > 'pta').
> > >
> > > Ok.
> > >
> > > > The constraint building is mostly gimple based (it doesn't use SSA),
> > > > so gimple-pta-constraints.{cc,h} might be appropriate and the pass
> > > > itself would be ssa-pta.{cc,h} since it puts the solutions on SSA
> > > > vars only.
> > >
> > > You say we should keep tree-ssa-structalias.cc and that the pass (the
> > > alias,
> > > ealias and ipa-pta passes, right?) should be in ssa-pta.{cc,h}. So you
> > > suggest
> > > splitting out the pass classes into ssa-pta.{cc,h}? I'm confused about
> > > which
> > > parts you think should then be in tree-ssa-structalias.cc and which in
> > > ssa-pta.cc.
> >
> > For now those pieces would remain in tree-ssa-structalias.cc. After all
> > reorg is complete we'd move that to ssa-pta.{cc,h}. So I suggest to
> > defer this part until it gets clear how this all plays out.
>
> Ah, ok. I see.
>
> > > Also, why not also rename tree-ssa-structalias.cc to be consistent? Is
> > > it a
> > > no-no to rename old files?
> >
> > See above.
> >
> > > If we ignored the fact that the constraint building doesn't really
> > > interact
> > > with SSA (but AFAIU, it benefits from SSA) and that the passes don't
> > > really
> > > modify gimple statements, we could have:
> > >
> > > pta-andersen.{cc,h}
> > > pta-steens.{cc,h}
> > > gimple-ssa-pta-constraints.{cc,h}
> > > gimple-ssa-pta.{cc,h}
> > >
> > > That seems nicer to me. A justification for calling those files
> > > gimple-ssa-*
> > > could be "to convey that this analysis happens on GIMPLE SSA IR". But
> > > you are
> > > the boss, of course.
> >
> > Sure, that works for me and follows existing practice.
> >
> > > Btw, I also thought about renaming the passes. ipa-pta is fine. But
> > > ealias
> > > and alias could be called epta and pta. That would convey what they are
> > > actually doing better, I think. It would also be more consistent with
> > > file
> > > names.
> >
> > Yeah, but that's a separate change affecting dump file names and
> > -fdisable-tree-XYZ only.
>
> I'll do that as a separate patch, then.
>
>
> I'll write a second version of this patch where I rename
> tree-ssa-structalias-andersen.{cc,h} to pta-andersen.{cc,h} and the
> structalias
> namespace to pta (and update the commit message accordingly). Can I consider
> that pre-approved?
Yes.
Richard.
> Thanks,
> Filip Kastl
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
