[llvm-dev] Potential issue with noalias @malloc and @realloc

[Daniel Berlin via llvm-dev]

>
>
> It seems to me that there are two ways of thinking about this: either the
> value of a pointer in IR is richer than its bit sequence, in which case
> replacing p1 with p0 in a block predicated by p0 == p1 is an incorrect
> transformation if you cannot prove that one pointer was based on the other,
>

Which would be a non-starter just from the cost of doing so, not to mention
the allowable optimization you lose :)

> or the value of a pointer in IR is exactly its bit sequence, in which case
> the code performing the transformation incorrectly updated the IR and a
> correct transformation would need to somehow remove the noalias from the
> malloc calls.
>

Sure, but noalias is just a symptom here. You can make the same thing occur
in other ways.  It's fundamentally an issue of being able to express when
the abstract identity of a pointer has changed even when the bit-value has
not.

IE there are enough transformation updates that need to occur that we
probably need to do something different than try to band-aid/patch all the
places that will have this issue.


The C++ object model formally takes the former standpoint; its pointers
> notionally point to objects, which are abstract entities occupying storage,
> rather than pointing to the storage itself.
>


Which, i get why they do (in fact i would do the same), but saying the
abstract objects have an identity outside of the bit values of the pointers
means that the IR's need to be able to represent identity changes
separately from value changes (this is what i meant by "add support for
describing lifetimes that has semantic meaning").
I'm not aware of any compiler that does this effectively, and it's a fairly
large semantic change.

They all pretty much hack it and hope they don't break too much shit.

Separately, changing noalias would just band-aid it. You can make the same
thing occur with TBAA, placement new, or really, any way we have where the
abstract identity may change but llvm doesn't express it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170412/b39afb4c/attachment.html>