[LLVMdev] [PATCH] Minor typos corrected in docs

[Reid Kleckner]

I can't apply this diff. Can you send the patch as an attachment?

On Thu, Feb 19, 2015 at 10:38 AM, Ralph Campbell <
ralph.campbell at broadcom.com> wrote:

>  I was reading various documents in the llvm/docs/ directory and found a
> few minor typos.
>
> I don’t have write access so if someone could apply these for me, that
> would be great.
>
>
>
> ---
>
>
>
> Index: docs/LangRef.rst
>
> ===================================================================
>
> --- docs/LangRef.rst        (revision 228410)
>
> +++ docs/LangRef.rst     (working copy)
>
> @@ -368,7 +368,7 @@
>
>       The idea behind this convention is to support calls to runtime
> functions
>
>      that have a hot path and a cold path. The hot path is usually a small
> piece
>
> -    of code that doesn't many registers. The cold path might need to call
> out to
>
> +    of code that doesn't use many registers. The cold path might need to
> call out to
>
>      another function and therefore only needs to preserve the caller-saved
>
>      registers, which haven't already been saved by the caller. The
>
>      `PreserveMost` calling convention is very similar to the `cold`
> calling
>
> @@ -521,7 +521,7 @@
>
> Global variables define regions of memory allocated at compilation time
>
> instead of run-time.
>
>  -Global variables definitions must be initialized.
>
> +Global variable definitions must be initialized.
>
>   Global variables in other translation units can also be declared, in
> which
>
> case they don't have an initializer.
>
> @@ -666,7 +666,7 @@
>
>   LLVM allows an explicit section to be specified for functions. If the
>
> target supports it, it will emit functions to the section specified.
>
> -Additionally, the function can placed in a COMDAT.
>
> +Additionally, the function can be placed in a COMDAT.
>
>   An explicit alignment may be specified for a function. If not present,
>
> or if the alignment is set to zero, the alignment of the function is set
>
> @@ -674,7 +674,7 @@
>
> is specified, the function is forced to have at least that much
>
> alignment. All alignments must be a power of 2.
>
>  -If the ``unnamed_addr`` attribute is given, the address is know to not
>
> +If the ``unnamed_addr`` attribute is given, the address is known to not
>
> be significant and two identical functions can be merged.
>
>   Syntax::
>
> @@ -716,7 +716,7 @@
>
> ``linkonce_odr``, ``weak_odr``, ``external``. Note that some system linkers
>
> might not correctly handle dropping a weak symbol that is aliased.
>
>  -Alias that are not ``unnamed_addr`` are guaranteed to have the same
> address as
>
> +Aliases that are not ``unnamed_addr`` are guaranteed to have the same
> address as
>
> the aliasee expression. ``unnamed_addr`` ones are only guaranteed to point
>
> to the same content.
>
>  @@ -1779,7 +1779,7 @@
>
>   LLVM IR floating-point binary ops (:ref:`fadd <i_fadd>`,
>
> :ref:`fsub <i_fsub>`, :ref:`fmul <i_fmul>`, :ref:`fdiv <i_fdiv>`,
>
> -:ref:`frem <i_frem>`) have the following flags that can set to enable
>
> +:ref:`frem <i_frem>`) have the following flags that can be set to enable
>
> otherwise unsafe floating point operations
>
>   ``nnan``
>
> Index: docs/CodeGenerator.rst
>
> ===================================================================
>
> --- docs/CodeGenerator.rst        (revision 227370)
>
> +++ docs/CodeGenerator.rst     (working copy)
>
> @@ -1340,7 +1340,7 @@
>
> If the indirect strategy is used, after all the virtual registers have been
>
> mapped to physical registers or stack slots, it is necessary to use a
> spiller
>
> object to place load and store instructions in the code. Every virtual
> that has
>
> -been mapped to a stack slot will be stored to memory after been defined
> and will
>
> +been mapped to a stack slot will be stored to memory after being defined
> and will
>
> be loaded before being used. The implementation of the spiller tries to
> recycle
>
> load/store instructions, avoiding unnecessary instructions. For an example
> of
>
> how to invoke the spiller, see
> ``RegAllocLinearScan::runOnMachineFunction`` in
>
> @@ -1353,7 +1353,7 @@
>
> instructions are three address instructions. That is, each instruction is
>
> expected to define at most one register, and to use at most two registers.
>
> However, some architectures use two address instructions. In this case, the
>
> -defined register is also one of the used register. For instance, an
> instruction
>
> +defined register is also one of the used registers. For instance, an
> instruction
>
> such as ``ADD %EAX, %EBX``, in X86 is actually equivalent to ``%EAX = %EAX
> +
>
> %EBX``.
>
>  @@ -1578,7 +1578,7 @@
>
>     correspond to. The MCInsts that are generated by this are fed into the
>
>     instruction printer or the encoder.
>
>  -Finally, at your choosing, you can also implement an subclass of
> MCCodeEmitter
>
> +Finally, at your choosing, you can also implement a subclass of
> MCCodeEmitter
>
> which lowers MCInst's into machine code bytes and relocations.  This is
>
> important if you want to support direct .o file emission, or would like to
>
> implement an assembler for your target.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/a11ecb9f/attachment.html>