[PATCH] [DOC] LangRef: Clarify when index of temporaries begin at 0

[Mikael Lyngvig]

Would you mind phrasing the sentence?  I'm simply not yet knowledgeable
enough about LLVM to be able to take all the many factors and issues into
consideration.  I am like a baby learning to walk, not an expert.

The purpose of the patch is solely to avoid the possibly frequent
experience that people gets confused when LLC complains about the first
temporary being named %0.  There's no other purpose with the patch.


-- Mikael


2013/11/27 Sean Silva <silvas at purdue.edu>

> This is still really not the right way to describe it. There's nothing
> special about the entry BB in this regard. Any BB without an explicit label
> gets an unnamed integer value assigned to it, and the counter is
> incremented.
>
> -- Sean Silva
>
>
> On Tue, Nov 26, 2013 at 10:24 PM, Mikael Lyngvig <mikael at lyngvig.org>wrote:
>
>> So what if I add this exact sentence after the place where the LR states
>> that temporaries begin at %0:
>>
>>     If a function entry block does not have an explicit label, it will
>> be assigned label “%0”, then the first unnamed temporary in that block will
>> be “%1”, etc.
>>
>> If you accept this, there's a patch for it attached to this message:
>>
>> diff --git a/docs/LangRef.rst b/docs/LangRef.rst
>> index 18d2c9c..5db1a14 100644
>> --- a/docs/LangRef.rst
>> +++ b/docs/LangRef.rst
>> @@ -128,7 +128,9 @@ lexical features of LLVM:
>>  #. Unnamed temporaries are created when the result of a computation is
>>     not assigned to a named value.
>>  #. Unnamed temporaries are numbered sequentially (using a per-function
>> -   incrementing counter, starting with 0).
>> +   incrementing counter, starting with 0). If a function entry block does
>> +   not have an explicit label, it will be assigned label "%0", then the
>> +   first unnamed temporary in that block will be "%1", etc.
>>
>>  It also shows a convention that we follow in this document. When
>>  demonstrating instructions, we will follow an instruction with a comment
>>
>>
>> -- Mikael
>>
>>
>>
>> 2013/11/27 Sean Silva <silvas at purdue.edu>
>>
>>>
>>>
>>>
>>> On Tue, Nov 26, 2013 at 10:01 PM, Mikael Lyngvig <mikael at lyngvig.org>wrote:
>>>
>>>> You're absolutely right (from the LR, I just searched):
>>>>
>>>>   For example, if a function entry block does not have an explicit
>>>> label, it will be assigned label “%0”, then the first unnamed temporary in
>>>> that block will be “%1”, etc.
>>>>
>>>> This is under Functions.  I guess anybody should get that far, but I
>>>> personally feel that the clarification I've submitted doesn't harm.
>>>>
>>>> Your current patch is inaccurate. If you want to duplicate what is
>>> mentioned elsewhere about the numbering to make it more likely that someone
>>> will see it, that would be OK.
>>>
>>> -- Sean Silva
>>>
>>>
>>>>
>>>> -- Mikael
>>>>
>>>>
>>>> 2013/11/27 Sean Silva <silvas at purdue.edu>
>>>>
>>>>> It is correct as written. Unnamed BB's are "unnamed temporaries" from
>>>>> a counting perspective. If the first BB is unlabeled, then it becomes %0.
>>>>> The first instruction then becomes %1, etc.
>>>>>
>>>>> I swear we mention that somewhere in LangRef (I seem to recall
>>>>> reviewing a patch mentioning that), but if not, a patch mentioning that
>>>>> would be fine.
>>>>>
>>>>> -- Sean Silva
>>>>>
>>>>>
>>>>> On Tue, Nov 26, 2013 at 8:50 PM, Mikael Lyngvig <mikael at lyngvig.org>wrote:
>>>>>
>>>>>> This patch adds the following sentence to the LR after it states that
>>>>>> temporaries begin at index 0:
>>>>>>
>>>>>>    If you do not specify a label for the entry block, the temporaries
>>>>>> start at index 1 as index
>>>>>>    0 is then used for an implicit label generated by LLVM.
>>>>>>
>>>>>> This because LLC complains when you use %0 as a temporary and there
>>>>>> is no entry point label in the function.  Then you get an error message,
>>>>>> which can be quite difficult to figure out why.
>>>>>>
>>>>>> If this patch is rejected, somebody should probably phrase the above
>>>>>> appropriately and submit a new patch.
>>>>>>
>>>>>>
>>>>>> -- Mikael
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> llvm-commits mailing list
>>>>>> llvm-commits at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131127/942af55f/attachment.html>