From: Philip Reames Date: Thu, 3 Mar 2016 23:24:44 +0000 (+0000) Subject: [docs] Add a description of current problem areas to the statepoint docs X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=2e7383cc1e46dcefd9e317ab4d156925f97c28e7;p=platform%2Fupstream%2Fllvm.git [docs] Add a description of current problem areas to the statepoint docs Triggered by a question on llvm-dev about status llvm-svn: 262671 --- diff --git a/llvm/docs/Statepoints.rst b/llvm/docs/Statepoints.rst index 1e46152..f951408 100644 --- a/llvm/docs/Statepoints.rst +++ b/llvm/docs/Statepoints.rst @@ -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 + `_ for more + detail. + Bugs and Enhancements =====================