<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 12, 2017 at 1:24 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><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"><span class="">On 12 April 2017 at 12:19, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_-3251515978729512752gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><div>Which would be a non-starter just from the cost of doing so, not to mention the allowable optimization you lose :) </div></div></div></div></blockquote><div><br></div></span><div>It may be possible to modify the optimization rather than losing it, such as by replacing p1 with barrier(p0) rather than with simply p0, where barrier(p) returns some pointer that is bitwise identical to p but may carry different ancillary data.</div><div><br></div><div>The way I'm thinking of this is that we have a semilattice of virtual values for each bit-pattern, where it's generally correct to move a value up in the lattice but not down; the barrier would return the top element of the lattice. Viewed this way, the problem is that replacing p1 with p0 may change to a value that is not at or above the original value in the semilattice. We could preserve more information when doing these value replacements by inserting an intrinsic representing join(p0, p1) instead of barrier(p0), but that seems like it would hinder further optimization rather than help it.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_-3251515978729512752gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></div></blockquote><div><br></div></span><div>I agree. Is it reasonable and feasible to require every optimization that replaces one (pointer) value with another value that is known to be bitwise-equal but not known to be semantically equivalent to -- somehow -- express that in the resulting IR?</div></div></div></div></blockquote><div><br></div><div><br></div><div>Yes.<br></div><div>It's not *practically* different than requiring them to do something like  "update memoryssa" (ie in terms of how you'd do it or where you'd do it) or in some cases "update ssa".</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"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><span class="m_-3251515978729512752gmail-"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></div></blockquote><div><br></div></span><div>Right. Even just for the noalias case, allocas would seem have the same problem as malloc:</div></div></div></div></blockquote><div><br></div><div><br></div><div>Yeah, though until we want to do a lot of work, i fear we should just be ignoring these issues until we have real world programs we are breaking :)</div><div> </div><div>I hate answers like that, but i feel like ATM it's more in the category of "something we should be cognizant of" than "something we should cut a wide swath through the compiler destroying optimizations to make work".</div><div><br></div><div>Maybe others feel differently, however.</div><div><br></div><div><br></div></div></div></div>