RPCSX/llvm
1
0
Fork 0
mirror of https://github.com/RPCSX/llvm.git synced 2024-11-27 13:40:30 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

[Statepoint docs] Delete trailing whitespace

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262730 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Sanjoy Das 2016-03-04 18:14:09 +00:00
parent 69cea5245f
commit f34ebb336e
1 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
docs/Statepoints.rst
View File

@ -794,37 +794,37 @@ 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
#. 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 gc-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
#. 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.
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.
#. 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
#. 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
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.
#. 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
=====================