> 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
On Wednesday 18 February 2009 21:43:30 DeLesley Hutchins wrote:> The majority of llvm users are using llvm to compile C, or things that are > similar to C.C++, objective C and Cg.> People who want to compile something other than C (Haskell, > ML, OCaml, C#, etc.) would benefit from from having type variables in the > IR.Absolutely. My HLVM is specifically designed to support MLs. However, I believe my project can only be completed with reasonable effort by building upon LLVM and taking a minimalist approach to placing requirements upon LLVM. I am not only avoiding contributing revolutionary changes to LLVM myself, I am avoiding everyone else's experimental features as well if at all possible.> 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).I agree completely but I do not believe that justifies making radical changes to LLVM itself. Indeed, you can do a perfectly good job by building upon LLVM precisely because LLVM does provide the esoteric low-level features that you want (e.g. tail call elimination is better in LLVM than on .NET!).> 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.Absolutely. I believe your proposal will not go ahead for non-technical reasons. That is not to say that it would not be wonderful to have a HLVM with such features that is built upon LLVM. Indeed, that is precisely what I am trying to accomplish. It will certainly not be theoretically optimal but it will exist and, I believe, it will be of great practical value. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e
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 >
> 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.I'm surprised you're happy with a non-polymorphic llvm. Does Cayenne target llvm? Dependent types take polymorphism to new heights -- but perhaps you feel that since llvm cannot hope to match Cayenne, you might as well do everything yourself. :-) My reasons are: First, if type variables are handled at the higher-level, then every functional language will have its own implementation. It will not be possible to define and reuse optimization passes between languages, which is one of the goals of llvm. Second, polymorphism can be made more efficient if it has low-level codegen support -- see my earlier offset code. Third, any language which has polymorphism is faced with the task of ``erasing'' it before it can hand the code to llvm. Such erasure can be done in different ways -- compare Java type erasure (use pointers, instantiate nothing), with C++ (instantiate everything), with .Net (instantiate some things). (I don't know how Ocaml does it) It is very difficult to share code between languages if the erasure semantics differ so widely. -DeLesley