[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