[LLVMdev] Unique shape and types

Chris Lattner sabre at nondot.org
Thu Jun 21 08:17:50 PDT 2007


On Thu, 21 Jun 2007, Nicolas Geoffray wrote:
> Chris Lattner wrote:
>> If you control the front-end, you have many options available to you.  For
>> example, you could emit your own tables along the same lines as debug
>> info but specialized to capture the metadata you need.
> Yes, but this always turns into having two representations for one type:
> the LLVM representation for its layout,
> and a personal representation for inheritance. Consider this example
> from a dynamic language which creates
> a new list of size four:
>
> (define a (new List 4))
>
> If LLVM had type inheritance integrated, all that would be needed is to
> emit the (new List 4) into LLVM instructions,
> get the returned type, and set it to the GlobalVariable a. This would
> simplify a lot of things (for me! :))

Unfortunately, that comes at a high cost.  The optimizers would then be 
tasked with maintaining this representation and not invalidating it. 
Also, the types would get in the way of many low-level optimizations.

>>> This leads to another question of type inference for dynamic languages

>> I don't propose to do that analysis on the LLVM IR itself. :)

> Ah, OK. So you propose to do type inference in (all) front-ends? Or
> maybe on a higher IR?

Yes, I'm proposing a common higher-level IR for languages like ruby, 
python, perl, etc.  I'll be giving a talk about it at OSCON this year. 
After the talk, I'll put slides up.

> Again, wouldn't it be easier for dynamic language front-end
> implementations if type inference was just a pass on the LLVM IR? I
> would surely _love_ to have thins kind of feature :)

It certainly would be easier for some people :).  That said, the LLVM IR 
shouldn't try to be all things to all people.  That is a sure recipe for 
doing all things really poorly for all people.

-Chris

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



More information about the llvm-dev mailing list