<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 16, 2016 at 11:11 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</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"><span class="gmail-">On 16 Nov 2016, at 19:03, Davide Italiano <davide@FreeBSD.org> wrote:<br>
><br>
>>><br>
>>> For our target, this is only sound if you can show that the pointer was<br>
>>> used to read all of the bytes that you are loading (we have byte-granularity<br>
>>> memory safety).  Old GVN has no hooks for targets to specify whether this is<br>
>>> safe and so is implicitly assuming a page-based MMU.  This optimisation is<br>
>>> also unsound for M-profile ARM cores, though will fail occasionally there,<br>
>>> whereas it fails deterministically for us.<br>
>>><br>
>>> Does it make any assumptions about the layout of memory in pointers?<br>
>><br>
><br>
> Which assumptions are you thinking of?<br>
<br>
</span>My last merge from upstream was about a year ago (and a new one is long overdue), but there were issues where GVN was assuming that if it did a load of a pointer then a ptrtoint, then a truncation, that it would get the same result as doing a narrower load.  This is not the case in any platform where pointers are not simply integers (i.e. where you actually need inttoptr / ptrtoint instead of bitcast).<br></blockquote><div><br></div><div>You keep talking about platforms, but llvm ir itself is not platform dependent.</div><div>Can you give a reference in the language reference that says that this is not legal?</div><div><br></div><div>IE what loads do *on your platform* is completely irrelevant to whether the IR code is legal or not, only what it codegens to.</div><div><br></div><div>LLVM's type semantics (and pointers may not have types, but the load operations produce values that do) are also not defined in terms of platform, but in terms of what datalayout says, etc.</div><div><br></div><div>What you want seems to be non-integral pointer types.</div><div><br></div><div>Which are experimental:</div><div><div class="gmail-section" id="gmail-non-integral-pointer-type"><p style="margin:0.8em 0px 0.5em">"LLVM IR optionally allows the frontend to denote pointers in certain address spaces as “non-integral” via the <a class="gmail-reference gmail-internal" href="http://llvm.org/docs/LangRef.html#langref-datalayout" style="color:rgb(202,121,0)"><span class="gmail-std gmail-std-ref">datalayout string</span></a>. Non-integral pointer types represent pointers that have an <em>unspecified</em> bitwise representation; that is, the integral representation may be target dependent or unstable (not backed by a fixed integer).</p><p style="margin:0.8em 0px 0.5em"><code class="gmail-docutils gmail-literal" style="font-family:consolas,"deja vu sans mono","bitstream vera sans mono",monospace;font-size:0.95em"><span class="gmail-pre">inttoptr</span></code> instructions converting integers to non-integral pointer types are ill-typed, and so are <code class="gmail-docutils gmail-literal" style="font-family:consolas,"deja vu sans mono","bitstream vera sans mono",monospace;font-size:0.95em"><span class="gmail-pre">ptrtoint</span></code> instructions converting values of non-integral pointer types to integers. Vector versions of said instructions are ill-typed as well."</p><p style="margin:0.8em 0px 0.5em"><br></p><p style="margin:0.8em 0px 0.5em">One of the reasons it's experimental is because nobody has made it work in all cases.</p><p style="margin:0.8em 0px 0.5em">I think whoever wants this to work is going to have to drive fixing it and making it work sanely.</p><p style="margin:0.8em 0px 0.5em"><br></p></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div></div>