[llvm-dev] RFC: Contained stateful AliasAnalysis

Alina Sbirlea via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 4 17:08:20 PST 2019


TL;DR: I'm looking to have AliasAnalysis passes have the ability keep a
temporary cache when no transformations are performed.

I'm interested to first and foremost clarify what is the best way to even
start such an infrastructure change, such that it is not abused (or even
available) by other passes. We certainly don't want to keep arbitrary
caches in all passes.
Would making this a feature used exclusively by MemorySSA make sense?
Only from other Analysis?

The usecases I have stem from BasicAA and TBAA being used to build
MemorySSA.
MemorySSA is essentially a cache itself, and we're building it with a
stateless tool.
We know that while building MemorySSA, there are no changes in the program,
and yet, there is info that is computed again and again.

One example is this patch: D57627 <https://reviews.llvm.org/D57627>. The
patch adds a cache for PointerMayBeCaptured, which is cleared after every
alias() call, in order to keep BasicAA stateless. In the example given in
the patch, not clearing the isCapturedCache reduces compile times by
another second. In some pathological cases I'm looking at, not-clearing
this cache halves compile times (from 8s to 4s).
There are a few other examples such as TBAA's getLeastCommonType and
BasicAA's DecomposeGEP.

Ideally we'd would have something along the lines of:
void keepCaches()
void clearCaches(),
with the first one called just before building MemorySSA, and the second
one called afterwards.

Again, I'm looking into how to make this available but also contain the
lifespan of these internal caches to only "as long as it takes for this
other analysis pass to be built".

Suggestions and feedback are most welcome!

Thanks,
Alina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190304/d68f9b2a/attachment.html>


More information about the llvm-dev mailing list