llvm dev - Aug 2014 - [LLVMdev] Functions with unnamed parameters in LLVM IR

On 13 August 2014 15:48, Tim Northover <t.p.northover at gmail.com>
wrote:
>> The above LLVM IR was confusing to me because I usually see that
>> unnamed registers start counting from 1 (i.e. %1 = add ...).
>
> There's a (usually hidden) %0 representing the entry basic block
> there. The general rule is "start from 0 and keep counting; skip named
> values".
Okay that's good to know. So unnamed arguments get assigned temporary
registers before the entry block? If so the entry block isn't always
%0.
>> I'm slightly surprised that unnamed function arguments are allowed
at
>> all. Maybe there is a use case but I can't think of a good one off
the
>> top of my head.
>
> They're useful for ensuring ABI conformance: padding out (hardware)
> registers that you don't want to use for a particular call.
>
> You might map void foo(int32_t a, int64_t b) to "declare void @foo(i32
> %a, i32, i64 %b)" for example, if your 64-bit value had to start at an
> even (32-bit) register number, as is the case on ARM. (Actually, it's
> not necessary there, but is in more complicated cases).
Thanks for the concrete use case.
>> I think it should be documented in the LLVM reference manual what the
>> register names are for unnamed arguments.
>
> It does sound reasonable to add a note that function arguments get
> included too, since they're not obviously value computations.
Included in what?

Anyway I've attached a patch that tries to clear this up. Is this good
enough to commit?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-note-to-LangRef-about-how-function-arguments-can.patch
Type: text/x-patch
Size: 1348 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140814/4535a568/attachment.bin>

> Okay that's good to know. So unnamed arguments get assigned temporary
> registers before the entry block? If so the entry block isn't always
> %0.
True.
> Included in what?
>
> Anyway I've attached a patch that tries to clear this up. Is this good
> enough to commit?
I did mean the LangRef, but probably not there, and not to that degree.

It's a fairly minor point, perhaps warranting a sentence where unnamed
values are generally discussed and the basic-block case is mentioned
(under the "Identifiers" section).

Cheers.

Tim.

> I did mean the LangRef, but probably not there, and not to that degree.
For documentation I think being explicit is much better than being implicit.
> It's a fairly minor point, perhaps warranting a sentence where unnamed
> values are generally discussed and the basic-block case is mentioned
> (under the "Identifiers" section).
I took a look at the "Identifiers" section [1]. There isn't any
mention of the basic-block case there. In any case I don't think this
is the appropriate place. Perhaps I've given you the wrong impression
about what I want to document.

What I want to documented is the fact that in a function definition,
arguments can be unnamed and that unnamed arguments are assigned to
temporary registers using the function's counter. The logical place to
discuss that is [2] (if I was a new user of LLVM and I wanted to know
about function arguments I wouldn't go looking at the identifiers
section). The entry block being assigned "%0" is discussed here too so
I could correct that as well.

On a separate note whilst looking at the Language reference I did
observe think a few things were odd

- We seem to mix the terms argument and parameter. Functions seem to
have arguments, but those arguments have "parameter attributes"
- We sort of use backus naur form to show the IR syntax but we don't
define things like "argument list" (what I'm trying to document),
"ret
attrs", "fn Attrs". For "ret attrs" and "fn
Attrs" we define what the
attributes are but we don't define the form of the list (i.e. space
separated).


[1] http://llvm.org/docs/LangRef.html#identifiers
[2] http://llvm.org/docs/LangRef.html#functions