llvm dev - Jun 2007 - [LLVMdev] Unique shape and types

Hi all,

In its implementation of types, LLVM only has one instance of a given 
shape, mostly for type equality (and I suppose projects like pool 
allocation requires it).

However, this leads to a somehow misleading bytecode representation. For 
example, consider the C++ program compiled with llvm-g++:

class AAA {
  int b;
};

class FFF {
  int a;
};

extern int foo(AAA * aaa);
extern int bar(FFF * aaa);


This gets compiled to

%struct.AAA = type { i32 }
%struct.FFF = type { i32 }

declare i32 @foo(AAA*)(%struct.AAA*)

declare i32 @bar(FFF*)(%struct.AAA*)


This is misleading because the bytecode tells us the argument type of 
bar is AAA. I suppose the name "@bar(FFF*)" helps the programmer
finding
that bar takes actually a FFF struct pointer.

Is this a non-issue for LLVM? Are types just considered as layouts?

The issue I'm facing is object inheritance and how to find from a LLVM 
type what types it inherits. Currently this can't be implemented in LLVM 
and I need to implement a higher representation for types.

Best,
Nicolas

On Wed, 20 Jun 2007, Nicolas Geoffray wrote:
> In its implementation of types, LLVM only has one instance of a given
> shape, mostly for type equality
> Is this a non-issue for LLVM? Are types just considered as layouts?
LLVM uses a structural type system, which is different than many source 
languages.  This is useful for the optimizer, but is not so useful if you 
want source level names.
> The issue I'm facing is object inheritance and how to find from a LLVM
> type what types it inherits. Currently this can't be implemented in
LLVM
> and I need to implement a higher representation for types.
Yep.  Sorry :(.  Depending on your application, you could read debug info, 
which captures all of this.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Chris Lattner wrote:
>
>> The issue I'm facing is object inheritance and how to find from a
LLVM
>> type what types it inherits. Currently this can't be implemented in
LLVM
>> and I need to implement a higher representation for types.
>>     
>
> Yep.  Sorry :(.  
"Sorry", like "this can really not be integrated in LLVM" or
like "it is
possible but it requires a lot of work to integrate it"? :)
> Depending on your application, you could read debug info, 
>   
Actually I am not using llvm-gcc. I'm just targeting a new language and 
it would have been a lot easier implementing the compiler with LLVM if 
it had this kind of feature (string <-> type). But if it's not
feasible,
well I'll just stick with my higher type representation.

This leads to another question of type inference for dynamic languages 
(I refer to your slides from the LLVM meeting day). I do not see how you 
can integrate type inference on objects in LLVM without knowning 
inheritance between types. Maybe you only target type inference to 
dissociate floating point values from integer or object values?


Nicolas