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

[Philip Reames via llvm-commits]

Author: reames
Date: Thu Mar  3 17:24:44 2016
New Revision: 262671

URL: http://llvm.org/viewvc/llvm-project?rev=262671&view=rev
Log:
[docs] Add a description of current problem areas to the statepoint docs

Triggered by a question on llvm-dev about status


Modified:
    llvm/trunk/docs/Statepoints.rst

Modified: llvm/trunk/docs/Statepoints.rst
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Statepoints.rst?rev=262671&r1=262670&r2=262671&view=diff
==============================================================================
--- llvm/trunk/docs/Statepoints.rst (original)
+++ llvm/trunk/docs/Statepoints.rst Thu Mar  3 17:24:44 2016
@@ -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
 =====================