<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 9:27 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.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 bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>On 09/08/2014 04:22 PM, Dan Gohman
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>An object can be allocated at virtual address 5 through
          extra-VM means (eg. mmap), and then one can (creatively)
          interpret the return value of @f as being associated with
          whatever %A was associated with *and* 5. The return value of
          @g can only be associated with exactly the same set that %A
          was associated with. Consequently, it's not always safe to
          replace @f with @g.<br>
        </div>
      </div>
    </blockquote></span>
    Dan, I'm trying to follow your logic here and am not arriving at the
    same conclusion.  Can you point out the flaw in my reasoning here?<br>
    <br>
    define i8* @f(i8* %A) {  <br>
    %pti = ptrtoint i8* %A to i64  <-- %pti is not a pointer and is
    thus not based on anything<br>
    %add = add i64 %pti, 5  <-- %add is not a pointer and is thus not
    based on anything, it is "associated with" the memory pointed to by
    %A<br>
    --- In particular, "5" is NOT a "an integer constant ... returned
    from
    a function not defined within LLVM".  It is not returned by a
    function.  As a result the pointer value of 5 is not associated with
    any address range.   <br></div></blockquote><div><br></div><div>I believe you misinterpreted the text here. 5 is "an integer constant other than zero", so it "may be associated with address ranges allocated through mechanisms other than those provided by LLVM".<br><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 bgcolor="#FFFFFF" text="#000000">
    %itp = inttoptr i64 %add to i8*  %itp is based on %pti only<br>
    ret i8* %itp}<br>
    <br>
    I'm guessing the key difference in our reasoning is about the
    constant 5.  :)  I'm also guessing that you have an example in mind
    which motivates the need for 5 to be considered associated with the
    address range.  Could you expand on why?<span class=""><br></span></div></blockquote><div><br></div><div>LLVM is used in a wide variety of contexts. In some of them, objects are statically allocated at known fixed addresses. In others, the JIT runs after objects are allocated, so it knows the address of allocated objects. In others, mmap is used to dynamically allocate objects at fixed addresses. The current rules attempt to accommodate all of these use cases, and more.<br><br></div><div>To respond to your suggestion elsewhere about using symbolic addresses that are resolved at link time, that's indeed a great technique, but not one that LLVM can require all its front-ends to use, because the practice of using integer constants is very widespread. It's even common enough at the C/C++ level. Also, in a JIT context, using symbolic addresses could require expensive and otherwise unnecessary relocation processing.<br><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 bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
          It looks a little silly to say this in the case of the integer
          constant 5, and there are some semantic gray areas around
          extra-VM allocation, but the same thing happens if the add
          were adding a dynamic integer value, and then it's difficult
          to find a way to separate that case from the constant 5 case.</div>
        <div><br>
        </div>
        <div>In any case, the general advice is that people should
          prefer to use getelementptr to begin with. LLVM's own
          optimizers were converted to use getelementptr instead of
          ptrtoint+add+inttoptr even when they have to do raw byte
          arithmetic.<br>
        </div>
      </div>
    </blockquote></span>
    It would be nice to be able to canoncalize ptrtoint+add+inttoptr to
    geps.  Having seemingly reasonable-looking legal IR that simply
    doesn't optimize is not the best introduction for new frontend
    authors.  :) <br></div></blockquote><div><br></div><div>I don't know if bitcast+getelementptr+bitcast is really worse than ptrtoint+add+inttoptr here. It's also my own experience writing front-ends that one most often gets into array and struct field accesses pretty quickly, and raw byte offsets only after getting into it a ways, so getelementptr shouldn't that foreign.<br></div></div></div></div>