[PATCH] D136512: [AA] Add aliasAt, for flow-sensitive queries.

[David Goldblatt via Phabricator via llvm-commits]

davidtgoldblatt created this revision.
Herald added subscribers: jeroen.dobbelaere, george.burgess.iv, hiraditya.
Herald added a project: All.
davidtgoldblatt updated this revision to Diff 469821.
davidtgoldblatt added a comment.
davidtgoldblatt added reviewers: nikic, jeroen.dobbelaere, wenlei, hiraditya, george.burgess.iv.
davidtgoldblatt added a subscriber: wenlei.
davidtgoldblatt published this revision for review.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Fixing an arc screwup


davidtgoldblatt added a comment.

This (and subsequent diffs in the stack) is something I've been experimenting with at Meta (hence the "facebook" comment markers, which are just an accident of our internal patch tracking and will get removed if this direction gets support).

The end goal is to allow library code to express aliasing invariants that it knows but that cannot be easily deduced by alias analyses. The simplest example of these is std::vector; modifications to its contents can't change the vector itself, but there's no way to deduce this in general (see e.g. this blog post: https://travisdowns.github.io/blog/2019/08/26/vector-inc.html). Instead, within the vector implementation, we can add `__builtin_experimental_separate_storage(this, this->_M_data)` in accessors; this is a new builtin that results in UB if the two arguments did not come from the same allocation.

This isn't ready to merge, because of the statelessness issue called out in `invalidate()`. If there is buy-in for the overall approach, I'm happy to generalize the assumption cache to support more than just assumptions, allowing an efficient implementation.

With a couple judicious insertions, it's shown promising results in some extracted performance-sensitive code kernels (around a 5% speed improvement in a thrift serialization function when we assert that the output buffer does not alias the thrift parse state, and around a 30% speed improvement to a numerical loop that became vectorizable when the array contents don't alias). Just inserting the hints into std::vector results in around an 0.05% improvement in generated code size in a variety of large server workloads. We can also add additional builtins to support things like std::string or SmallVector; using the current builtin would not be correct for them as written (because they embed their storage alongside their control data down certain paths).

This is vaguely similar to `restrict`, but `restrict` can't address some of the issues that these hints can. In particular, `restrict` is local to a function, and so can't propagate its semantic requirements to callers and callees after inlining.


davidtgoldblatt added a comment.

Removing from draft to get some feedback, but still more or less an RFC at the moment.

Added as reviewer anyone subscribed to AA changes + @wenlei, who's seen some of the evolution here.


Right now this is a stub, that always defers to the flow-insensitive
alias().


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136512

Files:
  llvm/include/llvm/Analysis/AliasAnalysis.h
  llvm/include/llvm/Analysis/BasicAliasAnalysis.h
  llvm/include/llvm/Analysis/CFLAndersAliasAnalysis.h
  llvm/include/llvm/Analysis/CFLSteensAliasAnalysis.h
  llvm/include/llvm/Analysis/GlobalsModRef.h
  llvm/include/llvm/Analysis/ObjCARCAliasAnalysis.h
  llvm/include/llvm/Analysis/ScalarEvolutionAliasAnalysis.h
  llvm/include/llvm/Analysis/ScopedNoAliasAA.h
  llvm/include/llvm/Analysis/TypeBasedAliasAnalysis.h
  llvm/lib/Analysis/AliasAnalysis.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D136512.469821.patch
Type: text/x-patch
Size: 13562 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221022/216c8469/attachment.bin>