[llvm] r262730 - [Statepoint docs] Delete trailing whitespace

[Sanjoy Das via llvm-commits]

Author: sanjoy
Date: Fri Mar  4 12:14:09 2016
New Revision: 262730

URL: http://llvm.org/viewvc/llvm-project?rev=262730&view=rev
Log:
[Statepoint docs] Delete trailing whitespace

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=262730&r1=262729&r2=262730&view=diff
==============================================================================
--- llvm/trunk/docs/Statepoints.rst (original)
+++ llvm/trunk/docs/Statepoints.rst Fri Mar  4 12:14:09 2016
@@ -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
 =====================