[LLVMdev] llvm::Type as llvm::Value in metadata

[Marcus Frenkel]

On Tue, Mar 27, 2012, 10:11 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Mar 26, 2012 at 11:48 PM, Marcus Frenkel
> <marcus.frenkel at fernuni-hagen.de> wrote:
>> On Tue, Mar 27, 2012 at 01:55 AM, Eli Friedman <eli.friedman at gmail.com>
>> wrote:
>>>
>>> On Mon, Mar 26, 2012 at 3:08 PM, Marcus Frenkel
>>> <marcus.frenkel at fernuni-hagen.de> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I've a question about something that's bothering me for quite some time
>>>> now: why is a llvm::Function seen as a llvm::Value (in a sense that
>>>> llvm::Function is a subclass of llvm::Value), but llvm::Type is not? Should
>>>> they not - technically seen - be equal?
>>>
>>>
>>> llvm::Function is a subclass of llvm::Value because you can use a
>>> llvm::Function as a value (of type pointer-to-function).  The same is
>>> not true for llvm::Type.
>>
>>
>> Yeah, I know that (in fact, I hoped to express exactly that ;) ). The
>> question is, why is that so?
>
> Types are purely a compile-time concept in LLVM IR, just like in C;
> there isn't any meta-type or reflection data associated with an LLVM
> type.
>
>> And how can you store references to llvm::Types
>> in the metadata section of a module?
>
> Essentially, you don't; you can store generic data in a string, though.
>
> -Eli
>

That's quite a pity, since unnamed types cannot be referenced by their name nor by their index or any other thing, but only by the pointer you get from llvm::StructType::get/llvm::ArrayType::get/..., am I right? Furthermore, one has to know the exact meaning of each string in the metadata (though it would probably be possible to do some name trickery to encode type names). However thanks for the answer.

Still, and just for the sake of interest, it would be nice to know about the reasons for this design decision (that means, why are llvm::Types not considered llvm::Values while llvm::Functions are).


Greetings

Marcus