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

Mon Jan 11 04:01:36 PST 2021

RalfJung added a comment.

> You mean not supported by codegen, right? It would still have been possible for somebody to use them in some intermediate-only use of LLVM. I agree with your more important points, though.

Yes.

> I do believe a boolean flag is sufficient for what's pragmatically required. I see a number of different kinds of questions that we want to be answered:

I think I see what you mean. My argument was, this boolean flag would not entirely remove the need for "syntactic foresight" from the semantics (to accurately describe what happens, we still have to determine which constrained allocas have disjoint lifetime). You seem to agree with this, but you also say that having the boolean flag could still help deal with allocas inside LLVM. I was thinking purely theoretically; I am happy to leave the pragmatic concerns to those familiar with the codebase. :) As long as we agree that "syntactic foresight" (and thus syntactic restrictions) is still required, I think we are on the same page here.

> I believe the problem is that we use the address/allocation "rules" to fold comparisons while we later "change" those rules. This patch tries to define a way out by differentiating allocas. I'm not sure anymore that is a good idea to begin with. Consistency could also be achieved by not using the "rules" to fold alloca comparisons to "not equal". We could instead coalesce allocas in the middle end (more aggressively and not only based on lifetime markers) in order to fold comparisons of the "then equal" allocas to "equal". That would not require us to assign different semantics to allocas depending on their uses, prevent us from restricting lifetime markers, and, probably most importantly, allow us to coalesce more without creating inconsistencies. First step is to check how often we fold alloca comparisons to "not equal". If that doesn't happen at all there seems little point in all of this. Even if not, an alternative, as sketched before, might very well perform at least as good while improving other aspects.

An interesting proposal, thanks! I must be missing some detail though: in general, coalescing allocas could change observable behavior if the program is comparing the addresses of these allocas. So why would that fold to "equal" be corrrect? I'd expect that if the lifetime markers do not affect alloca behavior, then two ptrs returned by different allocas will always compare inequal, so folding them to "equal" would be wrong.

> So the %c I added can be either true or false. false is probably clear, true becomes clear

if you argue that the pointer is dead outside it's lifetime and we could allocate/deallocate it "on demand".

I don't think `true` is permitted here. We have two allocations that clearly both exist at the same time (when the icmp happens), so absent lifetime markers this should be *guaranteed* to compare "inequal". I see no way to justify "true" here unless lifetime markers affect an object's address. What is the operational semantics of allocation and "icmp" that makes this happen (other than "icmp may non-deterministically always return true no matter the pointers", which I don't think is the semantics anyone wants)?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93376