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

[Jeroen Dobbelaere via Phabricator via llvm-commits]

jeroen.dobbelaere added a comment.

In D93039#2446719 <https://reviews.llvm.org/D93039#2446719>, @nikic wrote:

> While the concept of the intrinsic is intuitive, I think we're missing something here in terms of how it is formalized. I have a bit of a hard time formulating the rules.

The rules that I have in mind have more freedom. They are more like:

- `@llvm.noalias.decl` is something like a barrier that indicates where a noalias scope originates
- It should normally not be moved across block boundaries. (This is to avoid a declaration crossing a loop boundary)
- Moving it inside a block should pose no problems.
- When it is duplicated, care must be taken to see what to do with the noalias scope.
  - cases like loop unrolling and loop rotation: scope must be duplicated
  - cases like loop unswitching: no need to duplicate the scope
  - it should also not block optimizing away an 'almost empty loop' (in that case, the empty loop should be replaced by the `@llvm.noalias.decl`)
- instructions that have !alias.scope or !noalias metadata referring to the declared scope can be moved freely across the intrinsic.
- A `@llvm.noalias.decl` can be omitted if there is no `!alias.scope` metadata referring to the scope.
  - An `!alias.scope` usage, corresponds to a `@llvm.noalias/@llvm.ptr_provenance.noalias` usage in the full restrict version. When there are no more dependencies, the `@llvm.noalias.decl` intrinsic can be omitted.
- A missing `@llvm.noalias.decl` inside a function can lead to undefined behavior after inlining (and loop unrolling).
- Multiple `@llvm.noalias.decl` intrinsics in the same block, referring to the same scope can be merged.
- Multiple `@llvm.noalias.decl` intrinsics in the same block, referring to a different scopes can also be merged (but I would not yet do this).



> `if there is no `@llvm.noalias.decl` call for a certain scope contained in the function, the behavior is as if such a call were located at the start of the function.`

Not sure if we need to enforce this. For backwards compatibility it might be convenient (and expensive to check) to do this during inlining. But I would rather not do it there.


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

https://reviews.llvm.org/D93039