[llvm-dev] invariant.load metadata semantics

[Justin Lebar via llvm-dev]

My concern was just that, given what was happening with your Java
stuff, invariant.load might not be as strong as I thought.  But I am
satisfied on that count.

Thanks, Sanjoy!

On Mon, Aug 29, 2016 at 4:27 PM, Sanjoy Das
<sanjoy at playingwithpointers.com> wrote:
> Hi Justin,
>
> Justin Lebar wrote:
>>  > Yes, if you define "same pointer" as "pointers with the same bitwise
>> representation".
>>
>> Yes, this is the definition I was interested in, under the assumption
>> that it's the definition LLVM uses. But it sounds like you've augmented
>> LLVM so that bitwise-identical pointer values are not considered equal
>> if they come from different allocations.
>
> I may be misunderstanding you, but what you said above sounds
> misleading.  It isn't that we do some extra magic at the equality
> level, the magic we do is at the _allocation_ level.  The right mental
> picture is that we have a malloc that (magically) never runs out of
> memory, and our programs cannot explicitly call free or realloc on
> memory (so every allocation _is_, in fact, distinct).  This is not
> specific to GC'ed environments -- you could do the same thing in C++
> too, by adding (say) a programmer-level invariant (don't check in code
> that calls delete on class X, all instances of X live forever etc.).
>
> As an "optimization"[0] on top of that (this is the magic bit) we
> figure out which allocations are unnecessary from the program's point
> of view, and throw them away.
>
> Did that make sense?
>
> -- Sanjoy
>
> [0]: I'm being somewhat flippant here, this "optimization" is
>   basically the whole of the GC. :)