[llvm-dev] lifetime.start/end

[Michael Kruse via llvm-dev]

Am Di., 12. Jan. 2021 um 12:33 Uhr schrieb Ralf Jung via llvm-dev
<llvm-dev at lists.llvm.org>:
> I hope this question has not been answered yet, but I don't see how that fold
> could be legal. I asked the same question on Phabricator but it seems you prefer
> to have the discussion here. Taking your example from there and adjusting it:
>
> p = malloc(1)
> q = malloc(1)
> %c = icmp eq %p, %q
> free(q)
> free(p)
>
> I think there is a guarantee that c will always be "false". Every operational
> model of allocation that I have ever seen will guarantee this, and the same for
> every program logic that I can imagine. So if the compiler may fold this to
> "false", then as far as I can see, pointer comparison becomes entirely
> unpredictable. The only consistent model I can think of is "icmp on pointers may
> spuriously return 'true' at any time", which I doubt anyone wants. ;)

In my understanding of
https://timsong-cpp.github.io/cppwp/n3337/expr.rel#2.2 or
http://eel.is/c++draft/expr.rel#4.3 the result of this is unspecified.
While this does not necessarily extend to LLVM-IR, LLVM-IR usually
assumes C/C++ semantics unless defined otherwise.

Optimizations such as https://reviews.llvm.org/D53362 and
https://reviews.llvm.org/D65408 assume the equivalence of alloca and
malloc+free. I assume that such optimizations are the reason for this
unspecifiedness, i.e. I think someone might want this. Johannes's
proposal A1 however, seems to forbid StackColoring to exploit lifetime
markers, which it currently does and I am not sure we can afford to do
that.

Michael