[docs] Fix trailing whitespaces

[ljmf00]

Seem to be already fixed on the upstream default branch

llvm/docs/LangRef.rst

"``tailcc``" - Tail callable calling convention
     calling convention does not support varargs and requires the prototype of
     all callees to exactly match the prototype of the function definition.
 "``swiftcc``" - This calling convention is used for Swift language.
     - On X86-64 RCX and R8 are available for additional integer returns, and
       XMM2 and XMM3 are available for additional FP/vector returns.
     - On iOS platforms, we use AAPCS-VFP calling convention.
 "``swifttailcc``"
     This calling convention is like ``swiftcc`` in most respects, but also the
-    callee pops the argument area of the stack so that mandatory tail calls are 
+    callee pops the argument area of the stack so that mandatory tail calls are
     possible as in ``tailcc``.
 "``cfguard_checkcc``" - Windows Control Flow Guard (Check mechanism)
     This calling convention is used for the Control Flow Guard check function,
     calls to which can be inserted before indirect calls to check that the call
     target is a valid function address. The check function has no return value,
     but it will trigger an OS-level error if the address is not a valid target.
     The set of registers preserved by the check function, and the register
     containing the target address are architecture-specific.

 From the perspective of the optimizer, ``inttoptr`` and ``ptrtoint`` for
 non-integral types are analogous to ones on integral types with one
 key exception: the optimizer may not, in general, insert new dynamic
 occurrences of such casts.  If a new cast is inserted, the optimizer would
 need to either ensure that a) all possible values are valid, or b)
 appropriate fencing is inserted.  Since the appropriate fencing is
 implementation defined, the optimizer can't do the latter.  The former is
 challenging as many commonly expected properties, such as
-``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for non-integral types.  
+``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for non-integral types.
 
 .. _globalvars:
 
 Global Variables
 ----------------
 
 Global variables define regions of memory allocated at compilation time
 instead of run-time.

 
 Syntax:
 """""""
 
 ::
 
       declare token
         @llvm.experimental.gc.statepoint(i64 <id>, i32 <num patch bytes>,
-                       func_type <target>, 
+                       func_type <target>,
                        i64 <#call args>, i64 <flags>,
                        ... (call parameters),
                        i64 0, i64 0)
 
 Overview:
 """""""""
 
 The statepoint intrinsic represents a call which is parse-able by the

 implementation limitation.  Other than the type of the return value,
 the semantics are the same.
 
 Operands:
 """""""""
 
 The first and only argument is the ``gc.statepoint`` which starts
 the safepoint sequence of which this ``gc.result`` is a part.
-Despite the typing of this as a generic token, *only* the value defined 
+Despite the typing of this as a generic token, *only* the value defined
 by a ``gc.statepoint`` is legal here.
 
 Semantics:
 """"""""""
 
 The ``gc.result`` represents the return value of the call target of
 the ``statepoint``.  The type of the ``gc.result`` must exactly match
 the type of the target.  If the call target returns void, there will
 be no ``gc.result``.
 
 A ``gc.result`` is modeled as a 'readnone' pure function.  It has no
 side effects since it is just a projection of the return value of the
 previous call represented by the ``gc.statepoint``.
 
 'llvm.experimental.gc.relocate' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Syntax:
 """""""
 
 ::
 
       declare <pointer type>
-        @llvm.experimental.gc.relocate(token %statepoint_token, 
-                                       i32 %base_offset, 
+        @llvm.experimental.gc.relocate(token %statepoint_token,
+                                       i32 %base_offset,
                                        i32 %pointer_offset)
 
 Overview:
 """""""""
 
 A ``gc.relocate`` returns the potentially relocated value of a pointer
 at the safepoint.
 
 Operands:
 """""""""
 
 The first argument is the ``gc.statepoint`` which starts the
 safepoint sequence of which this ``gc.relocation`` is a part.
-Despite the typing of this as a generic token, *only* the value defined 
+Despite the typing of this as a generic token, *only* the value defined
 by a ``gc.statepoint`` is legal here.
 
 The second and third arguments are both indices into operands of the
 corresponding statepoint's :ref:`gc-live <ob_gc_live>` operand bundle.
 
 The second argument is an index which specifies the allocation for the pointer
 being relocated. The associated value must be within the object with which the
 pointer being relocated is associated. The optimizer is free to change *which*

llvm/docs/SourceLevelDebugging.rst

 
 Sometimes perfectly preserving variable locations is not possible, often when a
 redundant calculation is optimized out. In such cases, a ``llvm.dbg.value``
 with operand ``undef`` should be used, to terminate earlier variable locations
 and let the debugger present ``optimized out`` to the developer. Withholding
 these potentially stale variable values from the developer diminishes the
 amount of available debug information, but increases the reliability of the
 remaining information.
- 
 To illustrate some potential issues, consider the following example:
 
 .. code-block:: llvm
 
   define i32 @foo(i32 %bar, i1 %cond) {
   entry:
     call @llvm.dbg.value(metadata i32 0, metadata !1, metadata !2)
     br i1 %cond, label %truebr, label %falsebr

 presents several difficulties:
 
 .. code-block:: text
 
   define dso_local i32 @foo(i1 %cond, i32 %input) !dbg !12 {
   entry:
     br i1 %cond, label %truebr, label %falsebr
 
-  bb1: 
+  bb1:
     %value = phi i32 [ %value1, %truebr ], [ %value2, %falsebr ]
     br label %exit, !dbg !26
 
   truebr:
     call void @llvm.dbg.value(metadata i32 %input, metadata !30, metadata !DIExpression()), !dbg !24
     call void @llvm.dbg.value(metadata i32 1, metadata !23, metadata !DIExpression()), !dbg !24
     %value1 = add i32 %input, 1
     br label %bb1
 
   falsebr:
     call void @llvm.dbg.value(metadata i32 %input, metadata !30, metadata !DIExpression()), !dbg !24
     call void @llvm.dbg.value(metadata i32 2, metadata !23, metadata !DIExpression()), !dbg !24
     %value = add i32 %input, 2
     br label %bb1
 
-  exit: 
+  exit:
     ret i32 %value, !dbg !30
   }
 
 Here the difficulties are:
 
 * The control flow is roughly the opposite of basic block order
 * The value of the ``!23`` variable merges into ``%bb1``, but there is no PHI
   node
!11 = distinct !DISubprogram(name: "subroutine2", scope: !1, file: !1,
           line: 5, type: !8, scopeLine: 6,
           spFlags: DISPFlagDefinition | DISPFlagElemental, unit: !0,
           retainedNodes: !2)
 
 and this will materialize an additional DWARF attribute as:
 
 .. code-block:: text
 
-  DW_TAG_subprogram [3]  
+  DW_TAG_subprogram [3]
      DW_AT_low_pc [DW_FORM_addr]     (0x0000000000000010 ".text")
      DW_AT_high_pc [DW_FORM_data4]   (0x00000001)
      ...
      DW_AT_elemental [DW_FORM_flag_present]  (true)
 
 There are a few DWARF tags defined to represent Fortran specific constructs i.e DW_TAG_string_type for representing Fortran character(n). In LLVM this is represented as DIStringType.
 
 .. code-block:: fortran