It’s been a while since I looked into our Alias Analysis implementations, so take the rest of this with a grain of salt, but I don’t recall much in the way of flow-sensitivity in our implementation of BasicAA or the related analysis passes. I have a vague memory that some of the other analysis bits that compute mod-ref info and Memory SSA have some support for those types of queries, but it’s been long enough that I can’t be sure. I’ll defer to people like @jdoerfert who are much more in touch with the current state of affairs an can provide better guidance on what is in-tree today.
I do still remember some history, though. A long time ago, we had the DSA implementation in GitHub - llvm-mirror/poolalloc: Mirror kept for legacy. Moved to https://github.com/llvm/llvm-project, which I believe also could support flow-sensitive analysis, but that hasn’t been supported in a long time. It’s been quite a while since I read the original paper, so I may be incorrect about exactly what it supported.
A bit more recently, we had some (limited) implementations of Anderson and Steensgaard style analysis, but those were also removed (⚙ D139703 [AA] Remove CFL AA passes).
As for external projects, SVF(GitHub - SVF-tools/SVF: Static Value-Flow Analysis Framework for Source Code), Phasar(GitHub - secure-software-engineering/phasar: A LLVM-based static analysis framework.), and SeaDSA(GitHub - seahorn/sea-dsa: A new context, field, and array-sensitive heap analysis for LLVM bitcode based on DSA.) are referenced quite frequently in academic literature.I’ve had mixed results with these, but they’re under active development, and it’s been several years since I last tried to do anything serious with them, so you may not have the same issues I did.
Each framework is pretty different in its approach, but it should be possible to generate some kind of points-to sets using any of them. Phasar is probably the hardest to do so with, since its an IFDS/IDE framework, and I’m not sure they were ever able to port Boomerang (https://www.bodden.de/pubs/sna+16boomerang.pdf) to work with LLVM-IR. If you don’t actually need the points-to set, but can reduce your query to something expressible in IFDS, then it will probably work well. I found that in many cases, I didn’t actually need a points-to set, but could just use dataflow facts to get to the right answer. That completely depends on what you were trying to do w/ the analysis though. Also, IIRC the phasar maintainers were working on overhauling the points-to analysis, so its probably worth taking a look.
If you only need intra-procedural queries, SVF is likely the simplest and most straightforward, though I think it may not model all IR operations, like Insert/ExtractValue sufficiently for all usage. Depending on what you’re doing, that may not matter. Since I was analyzing IR from Rust, which lowers fat-pointer operations to
Insert/ExtractValue instructions it was a limitation I couldn’t easily work around. And again, the status there may have changed, since I know the authors are actively improving the library.
The big limitation I found w/ just about every framework for doing inter-procedural points-to analysis was scalability, primarily w.r.t. memory usage. I think this is still an open problem, and one I hope gets focus from the research community.
I know that was a lot of information you didn’t ask for, but hopefully some of it will be useful.