[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