[LLVMdev] [PATCH] Minor typos corrected in docs

Sean Silva chisophugis at gmail.com
Thu Feb 19 15:44:18 PST 2015 

On Thu, Feb 19, 2015 at 1:52 PM, Eric Christopher <echristo at gmail.com>
wrote:

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

For those interested, this was r229884.

-- Sean Silva


>
>
> -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
>>
>
> _______________________________________________
> 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/ab21c037/attachment.html>

More information about the llvm-dev mailing list