[PATCH] D147020: [AA] Add a tbaa-fence intrinsic.
David Goldblatt via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Mar 31 07:07:10 PDT 2023
davidtgoldblatt added a comment.
This doesn't necessitate any changes to TBAA (i.e. it doesn't have to try to identify the "source" of a pointer to know if it comes from a fence or not). Instead, what prevents incorrect behavior is that, since `llvm.tbaa.fence`'s memory effects are opaque (well, aside from being `ArgMemOnly`), the subsequent operation can't be reordered or eliminated. In this case, TBAA will still report NoAlias if asked about the two operations; but that result doesn't matter because you can't optimize based on that fact with a fence in between them (since the fence could, as far as the optimizer is concerned, do arbitrary loads and stores to the region of memory).
This intrinsic would work just as well for these purposes if it returned `void` and we got rid of the constraints about the subsequent accesses happening via the result of the call (and was truly just an opaque memory fence). I'd be happy to make that change if it'd be less confusing.
The only thing we get from having this return a value is the option to implement some optimizations later on; for example, in certain cases we can turn "store, fence, load" into a bitcast, letting us get rid of the fence's effects entirely.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D147020/new/
https://reviews.llvm.org/D147020
More information about the llvm-commits
mailing list