I'm totally noob on compilers internals, but if the processing of float arrays can be improved a lot by a LLVM ocamlopt, I would use it exclusively.
Le 3 déc. 2010 à 11:03, Benedikt Meurer a écrit : > So, let's take that LLVM thing to a somewhat more serious level (which means > no more arguing with toy projects that simply ignore the difficult stuff). > What would be necessary to support LLVM in ocamlopt, and what would be the > benefits? First, what has to be done: > > 1. Obviously, one would need to emit LLVM code from ocamlopt (starting at the > Cmm level). Following the GHC/EHC approach we could simply emit the .ll file > here as a starting point (no fiddling with the LLVM API then, could still > switch to the LLVM API later for runtime code generation). > > 2. LLVM would need to generate the stack maps for the GC and the required > symbols for the program (code_begin, code_end, data_begin, data_end). LLVM > already contains an OcamlGCPrinter class, which seems to do exactly this; so > this may be easy. > > 3a. If the current runtime is to be reused, LLVM will have to support OCaml > calling conventions (easy to implement, did that already), LLVM must be > taught about the OCaml runtime state (i.e. %r14 and %r15 on x86-64 must not > be used by LLVM, also easy to implement), and LLVM must be extended with > intrinsics to support allocation and exception handling with appropriate > lowering for the targets (somewhat difficult and questionable whether this > will be merged into LLVM, since it's usable by OCaml only). > > 3b. Alternatively we could also replace the native interface of the current > runtime with something that fits better with what is already provided by LLVM > (which isn't a lot, so we would have to limit ourselves somewhat). Allocation > and GC are possible without too many changes here, but the exception handling > is really difficult, since LLVM doesn't provide anything usable here; we'd > either need to do everything by hand or use one of the two modes provided by > LLVM (overhead, most probably). > > 4. We need a way to emit Cmm data items. LLVM cannot handle this ATM, which > should be fixed (dunno how yet). In the meantime we can emit Cmm data items > using module level asm. > > It is important to note that we won't get anything for free. Work is required > for every single platform we plan to support using the LLVM backend. This is > probably the case for every serious programming language (and no, we don't > need another mention of HLVM here, it's a toy, that's all). So, there's some > boring and probably some interesting work to be done, but what do we gain? > > 1. Reduce lines of code and improved maintainability of ocamlopt once all > targets are replaced with the LLVM backend. But as said, this does itself > come at a cost, and depending on whether 3a. or 3b. is implemented, we burden > ourselves with maintaining code within LLVM. > > 2. Some interesting optimizations and all the standard optimizations for free. > > 3. A better LLVM. If we do it right, other's implementing functional > languages using LLVM will not be faced with the same problems again. Dunno if > that's possible. > > 4. And for the kids: LLVM is cool, OCaml will use LLVM, so OCaml is also > cool. ;-) > > Anything I forgot to mention? Comments? > > Benedikt > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
