[LLVMdev] [PATCH] Minor typos corrected in docs

Thu Feb 19 13:52:39 PST 2015

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>