<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 1, 2016 at 11:24 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</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="auto">What kind of intrinsic are you thinking about here?</div></blockquote><div>I propose two intrinsics: llvm.lifetime.reuse and llvm.tbaa.pointer_identity.barrier.<br>Both intrinsics take at least one argument: an address value to the affected memory.<br>llvm.lifetime.reuse takes one other argument: the minimum size of the affected memory.<br>Both intrinsics return an address value: some version of the value passed in.<br><br>For llvm.tbaa.pointer_identity.barrier, the semantics are that the return address value is distinct from the argument in such a way that it achieves the necessary effect of std::launder with regards to TBAA.<br>Calls to llvm.tbaa.pointer_identity.barrier shall not be reordered with respect to each other (and thus, also functions which may perform such a call to llvm.tbaa.pointer_identity.barrier).<br>Note: it may be the case that, at this time, llvm.tbaa.pointer_identity.barrier only maintains an ordering between uses of its return value and the intrinsic itself.<br></div><div>Note: it may be possible to relax the reordering restriction based on the storage reachable from the argument pointer.<br></div><div><br>For llvm.lifetime.reuse(p, sz) (placement new):<br>Acts as llvm.tbaa.pointer_identity.barrier(p), except that the reachable storage contains at least [p, p + sz), with additional semantics as follows.<br><br>Conceptually, this kind of acts as (but is more prohibitive than) a store of undef over at least sz bytes over the memory starting at p (unfortunately, no TBAA information as to what it writes over is obvious from the immediate context at the source level).<br><br>Assuming that the loads and stores discussed below are ones which may access the affected memory:<br>This should mean that all loads observing previous stores should not, relative to the intrinsic, move to occur later.<br>(All stores observed by said loads should occur before said load).<br><br>If an invented load of the affected memory immediately before the intrinsic may observe a store, said store should should not, relative to the intrinsic, move to occur later;<br>however, if the invented load is the only observation of said store, the store should be removed as dead.<br><br>Thus, all accesses to a defined value of the old object must occur before the llvm.lifetime.reuse intrinsic (even if it is the intrinsic that it being moved).<br><br>By the language, either the old object type and the new object type already alias, or all accesses to the new object must either use the return value from llvm.lifetime.reuse, or the return value of a later llvm.tbaa.pointer_identity_barrier.<br>Thus, llvm.lifetime.reuse acts to separate accesses of the old object from accesses of the new object.<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="auto"><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>-- </div><div>Mehdi</div></font></span></div>
</blockquote></div><br></div></div>