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

[Johannes Doerfert via Phabricator via llvm-commits]

jdoerfert added a comment.

In D93376#2464019 <https://reviews.llvm.org/D93376#2464019>, @aqjune wrote:

> Are existing heap optimizations checking whether a malloc is used by lifetime.start/end?
> [...]
>
> In D93376#2463188 <https://reviews.llvm.org/D93376#2463188>, @jdoerfert wrote:
>
>> Sure. You could do the same transformation with heap objects under the same constraints. So you go from 
>> ... (snip)
>
> I think there are more cases to consider, such as:
>
>   p = malloc(1)
>   lifetime.start(p)
>   lifetime.end(p)
>   q = malloc(1)
>   // Can the addresses of p and q overlap?
>   free(q)
>   lifetime.start(p)
>   lifetime.end(p)
>   free(p)

Unsure why they would. I guess the idea of this example is related to the code gen use of lifetime markers, right? Similar to my argumentation for allocas,
the answer here could be true or false, and it is both legal, IMHO, as long as we are consistent. An example like this with allocas could result in a true
or false comparison between p and

> That is why I still prefer memset(undef); it may be a churn to teach that memset(undef) is a canonicalized form to e.g., loop dependence analysis, but teaching lifetime also needs churn.
> Most importantly, memset's semantics is crystal clear; it doesn't change the object's address. It also naturally supports a thing that is analogous to 'partial lifetime start'.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93376