<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 12, 2017 at 12:19 PM, 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: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=""><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></span><div>Which would be a non-starter just from the cost of doing so, not to mention the allowable optimization you lose :) </div><span class=""><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></span></div></div></div></blockquote><div>Also note, btw, the transformation did not incorrectly update the IR.   The store and the load were never noalias in the first place, becuase they were *always* talking about different abstract identities than the one that the malloc calls had.  It's just not expressed in the IR, and it  was not used to optimize until the other transformations occurred.</div><div><br></div><div>That is, with a smart enough optimization code, I could right now,  directly go from the start code to the end code with the IR as it appeared in the first example.</div><div>We just don't happen to.</div><div><br></div><div>Given good enough optimizers, there is no transformation update point to fix, there is only the missing semantic information that the abstract identity of the memory being stored and loaded is not the same as the abstract identity of the pointer returned by malloc.</div><div><br></div><div><br></div></div></div></div>