RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 10:42:39 +01:00
Code Issues Projects Releases Wiki Activity

[docs][statepoints] Reformulate open issues list

Browse Source 
Some have been partially resolved, so update that.  And restructure to make it easie to find and search.

llvm-svn: 346518
This commit is contained in:
Philip Reames 2018-11-09 17:09:16 +00:00
parent cb661fa4de
commit be340eedc1
1 changed files with 57 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
docs/Statepoints.rst
View File

@ -904,51 +904,69 @@ Today, only X86_64 is supported.
.. _OpenWork: .. _OpenWork:
Problem Areas and Active Work Limitations and Half Baked Ideas
============================= ================================
#. Support for languages which allow unmanaged pointers to garbage collected Mixing References and Raw Pointers
objects (i.e. pass a pointer to an object to a C routine) in the abstract ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
machine model. At the moment, the best idea on how to approach this
involves an intrinsic or opaque function which hides the connection between
the reference value and the raw pointer. The problem is that having a
ptrtoint or inttoptr cast (which is common for such use cases) breaks the
rules used for inferring base pointers for arbitrary references when
lowering out of the abstract model to the explicit physical model. Note
that a frontend which lowers directly to the physical model doesn't have
any problems here.
#. Support for garbage collected objects allocated on the stack. Specifically, Support for languages which allow unmanaged pointers to garbage collected
allocas are always assumed to be in address space 0 and we need a objects (i.e. pass a pointer to an object to a C routine) in the abstract
cast/promotion operator to let rewriting identify them. machine model. At the moment, the best idea on how to approach this
involves an intrinsic or opaque function which hides the connection between
the reference value and the raw pointer. The problem is that having a
ptrtoint or inttoptr cast (which is common for such use cases) breaks the
rules used for inferring base pointers for arbitrary references when
lowering out of the abstract model to the explicit physical model. Note
that a frontend which lowers directly to the physical model doesn't have
any problems here.
#. The current statepoint lowering is known to be somewhat poor. In the very Objects on the Stack
long term, we'd like to integrate statepoints with the register allocator; ^^^^^^^^^^^^^^^^^^^^
in the near term this is unlikely to happen. We've found the quality of
lowering to be relatively unimportant as hot-statepoints are almost always
inliner bugs.
#. Concerns have been raised that the statepoint representation results in a As noted above, the explicit lowering supports objects allocated on the
large amount of IR being produced for some examples and that this stack provided the collector can find a heap map given the stack address.
contributes to higher than expected memory usage and compile times. There's
no immediate plans to make changes due to this, but alternate models may be
explored in the future.
#. Relocations along exceptional paths are currently broken in ToT. In The missing pieces are a) integration with rewriting (RS4GC) from the
particular, there is current no way to represent a rethrow on a path which abstract machine model and b) support for optionally decomposing on stack
also has relocations. See `this llvm-dev discussion objects so as not to require heap maps for them. The later is required
<https://groups.google.com/forum/#!topic/llvm-dev/AE417XjgxvI>`_ for more for ease of integration with some collectors.
detail.
#. Support for alternate stackmap formats. For some use cases, it is Lowering Quality and Representation Overhead
desirable to directly encode a final memory efficient stackmap format for ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
use by the runtime. This is particularly relevant for ahead of time
compilers which wish to directly link object files without the need for The current statepoint lowering is known to be somewhat poor. In the very
post processing of each individual object file. While not implemented long term, we'd like to integrate statepoints with the register allocator;
today for statepoints, there is precedent for a GCStrategy to be able to in the near term this is unlikely to happen. We've found the quality of
select a customer GCMetataPrinter for this purpose. Patches to enable lowering to be relatively unimportant as hot-statepoints are almost always
this functionality upstream are welcome. inliner bugs.
Concerns have been raised that the statepoint representation results in a
large amount of IR being produced for some examples and that this
contributes to higher than expected memory usage and compile times. There's
no immediate plans to make changes due to this, but alternate models may be
explored in the future.
Relocations Along Exceptional Edges
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Relocations along exceptional paths are currently broken in ToT. In
particular, there is current no way to represent a rethrow on a path which
also has relocations. See `this llvm-dev discussion
<https://groups.google.com/forum/#!topic/llvm-dev/AE417XjgxvI>`_ for more
detail.
Support for alternate stackmap formats
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For some use cases, it is
desirable to directly encode a final memory efficient stackmap format for
use by the runtime. This is particularly relevant for ahead of time
compilers which wish to directly link object files without the need for
post processing of each individual object file. While not implemented
today for statepoints, there is precedent for a GCStrategy to be able to
select a customer GCMetataPrinter for this purpose. Patches to enable
this functionality upstream are welcome.
Bugs and Enhancements Bugs and Enhancements
===================== =====================