[llvm-dev] [RFC] NewGVN

[Daniel Berlin via llvm-dev]

On Wed, Nov 16, 2016 at 2:10 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> Hi all,
>
> Daniel Berlin via llvm-dev wrote:
>
>>     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).
>>
>>
>> You keep talking about platforms, but llvm ir itself is not platform
>> dependent.
>> Can you give a reference in the language reference that says that this
>> is not legal?
>>
>> IE what loads do *on your platform* is completely irrelevant to whether
>> the IR code is legal or not, only what it codegens to.
>>
>> 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.
>>
>> What you want seems to be non-integral pointer types.
>>
>> Which are experimental:
>>
>> "LLVM IR optionally allows the frontend to denote pointers in certain
>> address spaces as “non-integral” via the datalayout string
>> <http://llvm.org/docs/LangRef.html#langref-datalayout>. Non-integral
>> pointer types represent pointers that have an /unspecified/ bitwise
>> representation; that is, the integral representation may be target
>> dependent or unstable (not backed by a fixed integer).
>>
>> |inttoptr| instructions converting integers to non-integral pointer
>> types are ill-typed, and so are |ptrtoint| instructions converting
>> values of non-integral pointer types to integers. Vector versions of
>> said instructions are ill-typed as well."
>>
>>
>> One of the reasons it's experimental is because nobody has made it work
>> in all cases.
>>
>> I think whoever wants this to work is going to have to drive fixing it
>> and making it work sanely.
>>
>
> 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.
>

Oh, cool.


>
> 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).
>
Neat.


> I'm fine re-doing the same work on NewGVN (prevent inttoptr / ptrtoint on
> certain class of pointers).


Sure, i'm just saying "I don't think it's forbidden except in that case, it
sounds like a new feature".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161116/4328c9eb/attachment.html>