[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