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

40
docs/Statepoints.rst
View File

@ -904,10 +904,13 @@ Today, only X86_64 is supported.
.. _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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Support for languages which allow unmanaged pointers to garbage collected
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
@ -918,29 +921,45 @@ Problem Areas and Active Work
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,
allocas are always assumed to be in address space 0 and we need a
cast/promotion operator to let rewriting identify them.
Objects on the Stack
^^^^^^^^^^^^^^^^^^^^
#. The current statepoint lowering is known to be somewhat poor. In the very
As noted above, the explicit lowering supports objects allocated on the
stack provided the collector can find a heap map given the stack address.
The missing pieces are a) integration with rewriting (RS4GC) from the
abstract machine model and b) support for optionally decomposing on stack
objects so as not to require heap maps for them. The later is required
for ease of integration with some collectors.
Lowering Quality and Representation Overhead
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The current statepoint lowering is known to be somewhat poor. In the very
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
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 paths are currently broken in ToT. In
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
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
@ -949,7 +968,6 @@ Problem Areas and Active Work
select a customer GCMetataPrinter for this purpose. Patches to enable
this functionality upstream are welcome.
Bugs and Enhancements
=====================