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

[Sean Silva]

How does r195812 look to you?

-- Sean Silva


On Tue, Nov 26, 2013 at 10:40 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote:

> 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/20131126/8cf74ba8/attachment.html>