[llvm-dev] [RFC] NewGVN

[Sanjoy Das via llvm-dev]

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.

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

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

-- Sanjoy