<div dir="ltr"><div dir="ltr">On Mon, Jan 14, 2019 at 5:54 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><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 dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 14, 2019 at 5:44 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<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 dir="ltr">On Mon, Jan 14, 2019 at 5:03 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><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 dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 14, 2019 at 4:51 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<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"><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 14, 2019, 15:59 Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a> wrote:<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 dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 14, 2019 at 9:36 AM Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<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">While I'm very interested in the end result here, I have some questions that don't seem well answered yet around pointer subtraction...<div><br></div><div>First and foremost - how do you address correctness issues here? Because the subtraction `A - B` can escape/capture more things. Specifically, if one of `A` or `B` is escaped/captured, the subtraction can be used to escape or capture the other pointer. </div></div></blockquote><div><br></div><div>Isn't escaping supposed to work at the "address ranges" level and not at the pointer value?<br></div><div>I mean that if `A` or `B` is escaped/captured, then any pointer that is associated to the same memory range should be considered as "escaped", and thus the subtraction does not seem to leak anything more to me.</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I believe this is true for subtracting "inbounds" (to borrow the gep terminology), but just as we support non inbounds GEP, we support non imbounds subtracting. There it seems like this does escape the other global. I know that in the past I've discussed this exact case with nlewycky and he believed that to be the case, so I suspect quite a bit of LLVM is written under this model. No idea what would be the impact of changing it beyond the ability to represent code like the example I gave earlier on the thread. </div></div></blockquote><div><br></div><div>That does not match my current reading of LangRef (admittedly shallow/imperfect): not having inbounds allows you to form pointers that are outside of the memory range, however the "result value may not necessarily be used to access memory though, even if it happens to point into allocated storage".</div><div>Also the "pointer aliasing rules" section mentions: "Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined".</div></div></div></div></div></blockquote><div><br></div><div>I think there are still two issues here:</div><div><br></div><div>1) Escape of the address doesn't necessarily imply you can access the memory. It can still be an escaped address. It may not *alias* the memory, but that's a different question (confusingly). This means, for example, that a global may still be address-taken even though it cannot be accessed.</div></div></div></blockquote><div><br></div><div>I suspect we are out of the LangRef domain, but I'm surprised by this definition. Why is it useful to consider such address as "escaping"?</div><div>I'm not an expert on the literature, but I have always encountered the notion of escape analysis in relation with aliasing: it isn't the value of the pointer that is interesting to consider "escaped" but the memory it is pointing to.</div></div></div></div></blockquote><div><br></div><div>The use cases I'm aware of relate to the thing I mentioned in my comment. ;]</div><div><br></div><div>Imagine you have two functions. If the functions' addreses are escaped, than even though we may never read or write through those functions, the addresses must be *different* for different addresses. This is relevant in inferring things like `unnamed_addr` etc., and can impact constant (and function) merging semantics.</div><div><br></div><div>That said, there may be other uses as well.</div><div><br></div><div>Fundamentally, the *address* of an object and *aliasing* properties for that object are often somewhat independent. You see this with TBAA and "noalias" or "restrict" semantic models (only alias, not address).</div><div><br></div><div>-Chandler</div></div></div>