[PATCH] D93376: [LangRef] Clarify the semantics of lifetime intrinsics

Nuno Lopes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 17 12:08:41 PST 2020


nlopes added a comment.

In D93376#2461218 <https://reviews.llvm.org/D93376#2461218>, @jdoerfert wrote:

> What is the reason to restrict it to allocas? Just that we don't emit it right now? I don't see how that makes it conceptually better.

Potentially we could use these intrinsics with heap allocations such that after inlining they could maybe help to remove mallocs & friends. And maybe help alias analysis (Though the way basicAA works doesn't make implementing this any easy).
One of the reasons why it is restricted to allocas ATM is that the existence of `lifetime.start(%p)` determines that `%p = alloca` doesn't really allocate space right away. So we need to be able to syntactically determine all inputs to lifetime.start intrinsics. Which is harder if you start supporting non-alloca'ed objects, pointer arithmetic and everything else.
I suspect CodeGen would break right now if you use these intrinsics with non-alloca ptrs.

To summarize, I think we should restrict these intrinsics to alloca'ed ptrs for now as LLVM doesn't support anything else. If in the future someone extends them to support other kind of objects, then the semantics can be updated.

> This change looks to me like it tries to fix a set of issues and at the same time do something else, that is restrict the functionality based on some use case.

Not at all. It's just documenting the implicit assumptions all over LLVM's code, from IR to CodeGen. It's not changing anything. That's why we called out some CodeGen folks to ensure what's written reflects the assumptions of the stack coloring algorithm.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93376



More information about the llvm-commits mailing list