[LLVMdev] Parametric polymorphism
Lennart Augustsson
lennart at augustsson.net
Wed Feb 18 14:51:03 PST 2009
Why do you say that people who compile, e.g., functional languages
would benefit from type variables in LLVM?
I like the level the LLVM is at, and would prefer to deal with
instantiating parametric polymorphism at a higher level.
On Wed, Feb 18, 2009 at 10:43 PM, DeLesley Hutchins
<delesley.spambox at googlemail.com> wrote:
>> I think many people were confused by this at first but an excellent counter
>> example was provided in a previous thread: C99 ABIs can require that struct
>> return values are returned via a pointer to a preallocated struct passed as
>> an auxiliary argument *except* when you're talking about a C99 complex, in
>> which case the return value is conveyed in a completely different way.
>
> Thanks for the explanation. That definitely does make type instantiation in
> the IR a whole lot more annoying.
>
>>> I don't expect magic. If type specialization is implemented as an IR
>>> pass, then why couldn't post-specialization IR optimizations be
>>> performed?
>>
>> They could but my impression is that this will only ever be an academic
>> exercise: I doubt LLVM's type system will ever be changed in such a
>> fundamental way simply because the back-end is reaching maturity and that
>> would destabilize a large part of the library but also because there is no
>> clear advantage in doing that, not only for the majority of LLVM users but
>> also in the context of its goals.
>
> The majority of llvm users are using llvm to compile C, or things that are
> similar to C. People who want to compile something other than C (Haskell,
> ML, OCaml, C#, etc.) would benefit from from having type variables in the IR.
>
> Focusing too much on one language leads to a limited VM. Witness the
> JVM (only supports Java), or MSIL (designed for C#, with other features
> tacked on as an afterthought).
>
> What you say about maturity and destabilization is probably true, but
> that's more of a political problem or a manpower problem, not a technical
> problem.
>
> -DeLesley
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
More information about the llvm-dev
mailing list