[LLVMdev] Parametric polymorphism

Jon Harrop jon at ffconsultancy.com
Wed Feb 18 13:25:57 PST 2009


On Wednesday 18 February 2009 20:57:02 DeLesley Hutchins wrote:
> > It's done by the front-end. There are a variety of attributes and
> > mechanisms which are used to convolute data and marshall it through
> > call sites in an ABI-conformant manner.
>
> Oh dear.  :-(

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.

So this can only be done in the front-end.

> Do the attributes change depending on the type?  

You change the function signature depending whether the return type is a 
struct or not if you want C compatibility, if that is what you mean.

> >> I want llvm to do the specialization, because specialization is
> >> inextricably tied to similar optimizations, like inlining and
> >> partial evaluation.  Doing it within llvm has many advantages, such
> >> as JIT support and link-time optimization.
> >
> > These are IR-level optimizations, which LLVM does not magically do of
> > its own accord. If LLVM transparently performs specialization, then no
> > post-specialization IR optimizations can be performed.
>
> Since these are IR-level optimizations, the logical place to put type
> variables is in the IR.  If type variables only exist in the high-level
> language, then it's impossible for the llvm linker, JIT, or optimizers,
> or code generators to do anything intelligent with them.  :-)

What would you want them to do?

> 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.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e



More information about the llvm-dev mailing list