[PATCH] D93039: Introduce llvm.noalias.decl intrinsic

Jeroen Dobbelaere via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Jan 24 09:47:44 PST 2021


jeroen.dobbelaere added inline comments.


================
Comment at: llvm/lib/IR/Verifier.cpp:121
+    cl::desc("Ensure that llvm.experimental.noalias.scope.decl for identical "
+             "scopes are not dominating"));
+
----------------
fhahn wrote:
> jeroen.dobbelaere wrote:
> > nikic wrote:
> > > fhahn wrote:
> > > > jeroen.dobbelaere wrote:
> > > > > nikic wrote:
> > > > > > Can we flip this flag now, or are you aware of any further issues?
> > > > > I just did a test-suite run and a stage2 release build using an assertion build with the flag flipped, and both went fine. IMHO it makes sense to try it out...
> > > > > 
> > > > What's the impact on compile-time? If it is potentially expensive, it should probably be `true` for `EXPENSIVE_CHECKS` builds.
> > > I see no reason for it to be expensive at least.
> > @fhahn, @nikic, It's O(N log(N)) (sorting of N = number of scope declarations)
> > Next to that, it is roughly k * O((M-1)^2) * O(dominance checking) with M the the number of identical scope declarations, and k the number if different scopes.
> > In practice M should be pretty low (mostly 1) and O(N log(N)) should be the main part.
> > 
> > Is that considered to be too expensive ?
> > 
> > 
> IIUC we need to potentially check whether any `llvm.experimental.noalias.scope.decl` dominates any other `llvm.experimental.noalias.scope.decl`? 
> 
> 
> Is it possible to have a function with `N` basic blocks which do not dominate each other, each with `N` `llvm.experimental.noalias.scope.decl` for the same scope?
> Is it possible to have a function with `N` basic blocks which do not dominate each other, each with `N` `llvm.experimental.noalias.scope.decl` for the same scope?
It is allowed to construct such llvm-ir manually.
I am not aware on how to trigger this by an optimization pass, just based on declarations introduced by inlining.
My understanding is that most optimizations will not duplicate the intrinsic. The extra check is there to catch those optimizations that do and do it wrongly.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93039/new/

https://reviews.llvm.org/D93039



More information about the llvm-commits mailing list