<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 16, 2016 at 2:10 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<span class=""><br>
<br>
Daniel Berlin via llvm-dev wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
    My last merge from upstream was about a year ago (and a new one is<br>
    long overdue), but there were issues where GVN was assuming that if<br>
    it did a load of a pointer then a ptrtoint, then a truncation, that<br>
    it would get the same result as doing a narrower load.  This is not<br>
    the case in any platform where pointers are not simply integers<br>
    (i.e. where you actually need inttoptr / ptrtoint instead of bitcast).<br>
<br>
<br>
You keep talking about platforms, but llvm ir itself is not platform<br>
dependent.<br>
Can you give a reference in the language reference that says that this<br>
is not legal?<br>
<br>
IE what loads do *on your platform* is completely irrelevant to whether<br>
the IR code is legal or not, only what it codegens to.<br>
<br>
LLVM's type semantics (and pointers may not have types, but the load<br>
operations produce values that do) are also not defined in terms of<br>
platform, but in terms of what datalayout says, etc.<br>
<br>
What you want seems to be non-integral pointer types.<br>
<br>
Which are experimental:<br>
<br>
"LLVM IR optionally allows the frontend to denote pointers in certain<br>
address spaces as “non-integral” via the datalayout string<br></span>
<<a href="http://llvm.org/docs/LangRef.html#langref-datalayout" rel="noreferrer" target="_blank">http://llvm.org/docs/LangRef.<wbr>html#langref-datalayout</a>>. Non-integral<br>
pointer types represent pointers that have an /unspecified/ bitwise<span class=""><br>
representation; that is, the integral representation may be target<br>
dependent or unstable (not backed by a fixed integer).<br>
<br>
|inttoptr| instructions converting integers to non-integral pointer<br>
types are ill-typed, and so are |ptrtoint| instructions converting<br>
values of non-integral pointer types to integers. Vector versions of<br>
said instructions are ill-typed as well."<br>
<br>
<br>
One of the reasons it's experimental is because nobody has made it work<br>
in all cases.<br>
<br>
I think whoever wants this to work is going to have to drive fixing it<br>
and making it work sanely.<br>
</span></blockquote>
<br>
Hopefully this won't derail this thread -- but I plan to resume work on non-integral pointers very soon (mid December - early Jan).  Right now I'm busy with some higher priority things.<br></blockquote><div><br></div><div>Oh, cool.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We have the same problem as David C., btw, that GVN tends to freely convert between pointers and integers.  We have local patches that fix old GVN to DTRT, and the my plan was to upstream the custom patches predicated on the pointer types.  Same with instcombine (I don't remember if we have other patches).<br></blockquote><div>Neat.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm fine re-doing the same work on NewGVN (prevent inttoptr / ptrtoint on certain class of pointers).</blockquote><div><br></div><div>Sure, i'm just saying "I don't think it's forbidden except in that case, it sounds like a new feature".</div><div><br></div></div></div></div>