[PATCH] D102292: [docs] Add page on opaque pointer types

[David Chisnall via Phabricator via llvm-commits]

theraven added a comment.

In D102292#2757941 <https://reviews.llvm.org/D102292#2757941>, @dblaikie wrote:

> Yeah, that seems out of scope for this document. https://llvm.org/docs/LangRef.html#pointer-type documents that pointers to functions and pointers to other things are all roughly the same sort of thing - and we're changing all of them over to the opaque pointer type. & other wording generally treats all pointers as having the same size, etc. I think that's best left elsewhere than this doc if there's no interesting distinction between function pointers and data pointers currently (which it doesn't seem like there is).

Note that we have support for different code and data representations with the `P` flag in the DataLayout.  We can also differentiate between pointers to globals with G and there's an under-review patch for a specified address space for allocas.  I think it's worth highlighting in this document that address spaces are the recommended way of representing different kinds of pointers (with potentially different sizes, access to different types of memory, representations of null, and so on).  We retain the distinction between pointer types where the semantics matter for lowering, we lose the distinction when the distinction doesn't convey any useful meaning.



================
Comment at: llvm/docs/OpaquePointers.rst:17
+
+Anything to do with pointer address spaces is unaffected.
+
----------------
I don't think this needs stating, especially given how important address spaces are in motivating this work: The need to cast to `i8*` makes a lot of code need to be AS-aware if integrates with code that uses address spaces, whereas with opaque pointers you don't need the bitcasts and so you don't need to care about the pointer AS.  



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102292/new/

https://reviews.llvm.org/D102292