> 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. :-( Do the attributes change depending on the type? I would assume that attributes like "ccc" are type-invariant; i.e. every instantiation should use the C-calling convention, whatever that happens to be for the types in question.>> 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. :-) I don't expect magic. If type specialization is implemented as an IR pass, then why couldn't post-specialization IR optimizations be performed? -DeLesley
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
> 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