Skip to content

Commit 374bb6d

Browse files
committed
[docs] Update opaque pointers transition state (NFC)
Bitcode is now supported.
1 parent dcc4b94 commit 374bb6d

File tree

1 file changed

+13
-13
lines changed

1 file changed

+13
-13
lines changed

llvm/docs/OpaquePointers.rst

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,8 @@ Address spaces are still used to distinguish between different kinds of pointers
1818
where the distinction is relevant for lowering (e.g. data vs function pointers
1919
have different sizes on some architectures). Opaque pointers are not changing
2020
anything related to address spaces and lowering. For more information, see
21-
`DataLayout <LangRef.html#langref-datalayout>`_.
21+
`DataLayout <LangRef.html#langref-datalayout>`_. Opaque pointers in non-default
22+
address space are spelled ``ptr addrspace(N)``.
2223

2324
Issues with explicit pointee types
2425
==================================
@@ -191,24 +192,23 @@ on a pointer type.
191192
Transition State
192193
================
193194

194-
As of Febuary 2022 large parts of LLVM support opaque pointers. It is possible
195-
to build a lot of C and C++ code in opaque pointer mode, both with and without
195+
As of March 2022 most parts of LLVM support opaque pointers. It is possible
196+
to build most C and C++ code in opaque pointer mode, both with and without
196197
optimization, and produce working binaries. However, thes are still some major
197198
open problems:
198199

199-
* Bitcode already fully supports opaque pointers, and reading up-to-date
200-
typed pointer bitcode in opaque pointers mode also works. However, we
201-
currently do not fully support pointee type based auto-upgrade of old bitcode
202-
in opaque pointer mode.
203-
204200
* While clang has limited support for opaque pointers (sufficient to compile
205201
most C/C++ code on Linux), a major effort will be needed to systematically
206202
remove all uses of ``getPointerElementType()`` and the deprecated
207203
``Address::deprecated()`` constructor.
208204

209-
* We do not yet have a testing strategy for how we can test both typed and
210-
opaque pointers during the migration. Currently, individual tests for
211-
opaque pointers are being added, but the bulk of tests still uses typed
212-
pointers.
205+
* We do not yet have a firm strategy for enabling opaque pointers. A large
206+
number of tests will have to be migrated to use opaque pointers.
207+
208+
* Some pointer element type uses remain in LLVM.
209+
210+
* Some pointer element type uses remain in LLDB.
211+
212+
* Some pointer element type uses remain in MLIR.
213213

214-
* Miscellanous uses of pointer element types remain everywhere.
214+
* Some pointer element type uses remain in Polly.

0 commit comments

Comments
 (0)