On Sun, 12 Dec 2010 20:09:00 +0100 Benedikt Meurer <benedikt.meu...@googlemail.com> wrote:
> > On Dec 12, 2010, at 16:55 , Török Edwin wrote: > > > [...] > > Problem #2: Int64.div n 2 -> idiv instruction. > > > > A C compiler would optimize this to a right shift. Changing that to > > 'Int64.shift_right n 1' speeds up the code. > > This is easy to fix in ocamlopt (see attached patch > ocamlopt-natint.patch), by applying the same optimizations already > used for constant int's to constant natint's (Int64 is Nativeint on > 64bit). Nice patch. I definitely agree that what can be fixed in ocamlopt's high-level opts should be fixed there, rather than hope that LLVM will just do everything. > [...] > > > > One advantage of using LLVM is that it would notice arithmetic > > optimizations like this and perform it itself (even if you use the > > boxed representation). > > In case of x86-32, it won't, simply because LLVM will be presented > with the calls to caml_int32_* functions. I was thinking that the runtime could be compiled to .bc, and then they would get inlined and optimized away at link time. That is overkill for something as simple as integer arithmetic, but could be useful for more complicated runtime functions (or C bindings). > You'd need to change the > Cmm code instead (changing the low-level stuff is straight-forward as > demonstrated). I agree that not emitting those C calls in the first place is better. > For 64bit targets, see attached patch. > > This doesn't mean that LLVM wouldn't be useful (in fact, I've just > started an LLVM backend for ocamlopt). Great! If you notice some more optimizations missed by ocamlopt while working on it, could you write up a list of those? I think I suggested earlier in this thread that LLVM could be used in two ways: write a backend with it, or port some of the LLVM optimizations to ocamlopt. Maybe it'd be good to write some documentation on ocamlopt's internals, and how one can add more optimizations there. Something simple like what is the IR format (like LLVM's langref), how you perform the optimizations (what is the equivalent of LLVM's passes), and what helper modules can you use (what is the equivalent of LLVM's analysis) would suffice for a start. Does something like this exist already? > But it is important to note > that LLVM is not the solution to everything. As the name implies, > it's "low level", it does a few "higher level" optimizations for C, > but these are special cases (and somewhat ugly if you take the time > to read the code). It won't make a faster OCaml magically, just like > it didn't make a faster Haskell by itself. > > I could go on by quoting common "Harrop jokes" like "you need types > in the low-level IR", etc. trying to tell him that this is simply > wrong; but after reading through the Caml/LISP mailing list archives > (thanks for the pointers by several readers), I'm pretty much > convinced that Jon simply decided to end his war against LISP just to > start a new one against ocamlopt. > > If anyone is serious about ocamlopt with LLVM, feel free to contact > me (tho, my time is limited atm). I wouldn't have much time to dedicate to this, so I can't say I'm serious about it. AFAICT LLVM's OCaml bindings are only good for generating LLVM IR from OCaml, not for actually performing transformations on it (there is no binding to retrieve the type of a value for example). I'll probably be looking into fixing that in the near future, and this may indirectly help your LLVM backend (if you intend to write OCaml specific transformations on the LLVM IR). Best regards, --Edwin _______________________________________________ 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
