[LLVMdev] Parameter names in IR and debug info

[Rodney M. Bates]

On 02/19/2015 01:38 PM, David Blaikie wrote:
>
>
> On Thu, Feb 19, 2015 at 8:18 AM, Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote:
>
>     Have I correctly inferred below, how I build IR and debug info for
>     a function type and a function (value), in particular, how to supply
>     the names of the formal parameters?
>
>
> Generally good advice: http://llvm.org/docs/tutorial/LangImpl8.html
>
>     To create a function in llvm IR and give names to its formal parameters,
>     I must:
>
>     1. Build a LLVMTypeRef for the type of each formal and the function result.
>
>
> Sounds like you're using the C API. I'm not especially familiar with that, so answers may be vague.
>
>     2. Build a function type using LLVMFunctionType, from the results of 1.
>     3. Build a function (an LLVMValueRef), using LLVMAddFunction, from the result of 2.
>     4. Get the LLVMValueRef for each formal (apparently, these are constructed inside
>         LLVMAddFunction), using LLVMGetParam, from the result of 3.
>     5. Set the formal name using LLVMSetValueName, from each result of 5.
>
>
> The names of LLVM IR values are purely aids for LLVM developers (such as yourself), they should never have any impact on the result of LLVM (in terms of machine asm/code - the textual LLVM IR will include the names, but again, this is just a debugging aid for you, the LLVM developer (it has no impact on the DWARF debug info LLVM emits))
>

Thanks, that's useful info.  I had wondered about that.  In any case, I think I
want the names just to help looking at IR code.

>     Which appears to imply that the formal names are part of the function,
>     not the function type, and thus the function type could be reused for another
>     function whose signature differs only in the names of the formals.  Also the
>     function type could be used as the referent of a pointer type, which could
>     then be used as the type of a variable, without any actual function at all.
>
>
> Sure.
>
>
>     To build corresponding debug info, I must:
>
>     6. Build a llvm::DIArray, using llvm::getOrCreateArray, from the results of 4.
>     7. Build a llvm::DIComposite type for the function, using
>         llvm::createSubroutineType, from the result of 6.
>     8. Build a llvm::DIFunction using llvm::createFunction, from the result of 7.
>
>     Here, I need the formal values, with names, first, before building the function
>     type.
>
>
> I don't think you should need parameter names for createSubroutineType - it's just a type (composed of other types, no variable names, just type names).
>

That's what I might have expected, but ... createSubroutineType wants a DIArray, and its
creator getOrCreateArray, takes a list of Value*, not Type*.
(The Kaleidoscope chapter 8 uses getOrCreateTypeArray, returning DITypeArray, neither
of which shows up in a systematic grep of the entire source tree.)

>     This appears to imply that, in debug info, the formal names are also part
>     of the function type,
>
>
> Shouldn't be. But the actual DWARF output doesn't necessarily have explicit function types - it just has a function with some formal parameters, each with a type and in a specified order.
>
>     which thus cannot be reused for a different function with
>     different formal names.
>
>     Can I build a DI function type without having an actual function of that type?
>     This happens in my language.
>
>
> Not sure I understand. You mean your language has, say, a function pointer even though you have no function of that type. Certainly clang does this (try compiling something simple like "void (*x)();" in clang and look at the LLVM IR it produces - you'd want to produce something similar).
>

Yes, actually, the HLL view is there are procedure types (not pointers to) that take values of
any procedure whose signature meets a certain structural similarity criterion (weaker than equality)
with the type.  Of course, pointers are used in the implementation, but this is a lowering from
the source code, complicated by the fact that sometimes the value can be a nested procedure, needing
an environment.

In order to support reasonable debugger behavior, using source language concepts, I need debug info for
procedure types to have parameter names.  And better debugger behavior is one major reason for
connecting to an llvm back end.

One thing that makes it harder to figure out what I need to do is that many examples, e.g., clang-produced
IR for sample C programs, give assembly.  Translating this into the sequence of calls needed to
build the in the in-memory form of IR is not always obvious.

Actually, I am increasing doubting the wisdom of my initial decision to generate llvm IR this
way.  Maybe generating an assembly or bitcode file directly would be better.

> - David
>
>
>
>     --
>     Rodney Bates
>     rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>
>     _________________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>

-- 
Rodney Bates
rodney.m.bates at acm.org