[PATCH] D22488: [IR] Introduce a non-integral pointer type

[Matt Arsenault via llvm-commits]

arsenm added inline comments.

================
Comment at: docs/LangRef.rst:559-561
@@ +558,5 @@
+via the :ref:```datalayout`` string<langref_datalayout>`.  Values of the
+non-integral pointer type represent pointers that don't have a *stable* bitwise
+representation; that is at runtime they may not be backed by a fixed unchanging
+pointer-width integer.
+
----------------
sanjoy wrote:
> sanjoy wrote:
> > arsenm wrote:
> > > sanjoy wrote:
> > > > arsenm wrote:
> > > > > What consequence does the changing pointer value have on the optimizer? I'm interested in this for fat pointers which will not change value during runtime
> > > > That is the justification for disallowing integer <-> pointer conversions (directly via cast instructions or via memory).  If fat pointers have a stable bitwise representation, then why not represent them as normal pointers?
> > > > 
> > > The pointer arithmetic does not behave exactly like a 128-bit integer. Doing pointer arithmetic such as a 128-bit add would be incorrect, and we don't want CodeGenPrepare etc. to be allowed to decompose it into integer operations.
> > > 
> > > The high 64-bits are constant "metadata" bits for the memory operation. The low 64-bits behave like a pointer. I think what we need is something that would only ever have the pointer manipulated through GEP, and then special addressing mode matching in the backend (since the fat pointer should almost always be treated as a constant with a separate index operand)
> > Okay, that sounds reasonable.  We have a similar restriction, in that GEPs have to stay GEPs and can't be decomposed into integer arithmetic.  However, we also want to allow things like alignment, which only really make sense if the pointer has an integral representation.   What do you think of changing the language to say "does not have a useful integral representation"?  "useful" is deliberately vague here, with the understanding that we disallow some integer-like operations / properties, but allow others.
> > we also want to allow things like alignment
> 
> Just to be explicit: I meant we also want to allow specifying things like alignment on these non-integral pointers
That seems ok. The low bits are pointer like, so alignment still would make sense for our case


https://reviews.llvm.org/D22488