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.
Also, why not also rename tree-ssa-structalias.cc to be consistent? Is it a
no-no to rename old files?
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.
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.
Cheers,
Filip Kastl
