thr3ads.net - llvm dev - [LLVMdev] [PATCH] Minor typos corrected in docs [Feb 2015]

If this information is useful, please help other people find it:
Share via:

Ralph Campbell

2015-Feb-19 18:38 UTC

[LLVMdev] [PATCH] Minor typos corrected in docs

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/d99bc1ea/attachment.html>

Reid Kleckner

2015-Feb-19 21:48 UTC

head link

[LLVMdev] [PATCH] Minor typos corrected in docs

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>

Eric Christopher

2015-Feb-19 21:52 UTC

head link

[LLVMdev] [PATCH] Minor typos corrected in docs

I already got it earlier, apologies for not replying to the list.

-eric

On Thu Feb 19 2015 at 1:50:13 PM Reid Kleckner <rnk at google.com> wrote:
> 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
>>
>>
> _______________________________________________
> 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/f7e8898b/attachment.html>

Possibly Parallel Threads

Search for more apparently analagous threads

llvm dev - Feb 2015 - [LLVMdev] [PATCH] Minor typos corrected in docs

[LLVMdev] [PATCH] Minor typos corrected in docs

[LLVMdev] [PATCH] Minor typos corrected in docs

[LLVMdev] [PATCH] Minor typos corrected in docs

Possibly Parallel Threads