<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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, </div></div></div></div></blockquote><div><br></div><div>Which would be a non-starter just from the cost of doing so, not to mention the allowable optimization you lose :) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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. </div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div><div><br></div><div>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").</div><div>I'm not aware of any compiler that does this effectively, and it's a fairly large semantic change.</div><div><br></div><div>They all pretty much hack it and hope they don't break too much shit.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div></div></div>