RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-18 18:42:46 +02:00
Code Issues Projects Releases Wiki Activity

[docs] Add a description of current problem areas to the statepoint docs

Browse Source 
Triggered by a question on llvm-dev about status

llvm-svn: 262671
This commit is contained in:
Philip Reames 2016-03-03 23:24:44 +00:00
parent a7fc8e012e
commit 347970f4ae
1 changed files with 35 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
docs/Statepoints.rst
View File

@ -791,6 +791,41 @@ Supported Architectures
Support for statepoint generation requires some code for each backend.
Today, only X86_64 is supported.
Problem Areas and Active Work
=============================
#. As the existing users of the late rewriting model have matured, we've found
cases where the optimizer breaks the assumption that an SSA value of
gc-pointer type actually contains a pointer and vice-versa. We need to
clarify our expectations and propose at least one small IR change. (Today,
the gc-pointer distinction is managed via address spaces. This turns out
not to be quite strong enough.)
#. Support for languages which allow unmanaged pointers to garbage collected
objects (i.e. pass a pointer to an object to a C routine) via pinning.
#. 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.
#. 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
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
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.
Bugs and Enhancements
=====================