Ocaml back-end

Ocaml back-end

[Gilles Pirio]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

NOTE: sorry for double posting but I've been informed that my initial post
(in google group - I usually read the group from there) would not be
forwarded to the caml list as I naively thought...

---------------

Hi all

I've been busy changing/implementing (new) passes in ocamlopt back-end
for my own target. A collateral of that is that it improves the
generated code for x86 -- ocamlopt is great but isn't exactly an
optimizing compiler :) Simple constant propagation and invariant code
motion sometimes doesn't happen. Below is trivial example -- the if i/
9 >s 201 test may be removed at some stage. I've seen lots of things
like it. This generates inefficient code (on x86 and ARM at least).
I've had up to 30% speed improvement. Of course, the speed can also be
improved by modifying the Ocaml code itself, so I'm not claiming what
I've done is a major improvement at all.

camlA__matchdtree_63(R/0[%eax])
  { + R/0[%eax]}
  a/8 := R/0[%eax]
  {a/8*}
  i/9 := 1
  {a/8* i/9}
  catch
    {a/8* i/9 + i/9}
    if i/9 >s 201 then
       [...]

Short questions --
(1) Any optimizing option I would be unaware of? Inlining option
doesn't help much.
(2) Any way to contribute this work back to Ocaml community (on a
separate cvs branch?) or is this kind of work planned by the core
Ocaml team?
Thanks,
G<>

[-- Attachment #2: Type: text/html, Size: 1606 bytes --]

Re: [Caml-list] Ocaml back-end

[Edgar Friendly]

Gilles Pirio wrote:
> (2) Any way to contribute this work back to Ocaml community (on a
> separate cvs branch?) or is this kind of work planned by the core
> Ocaml team?
> 
> Thanks,
> G<>

Well, I can give you access to an unofficial public git mirror of
INRIA's cvs.  I use it to build my compiler, but I dunno if anyone else
uses it.  If it had optimizations like this, they might very well.

I don't expect INRIA to work on such optimizations in the near future -
they seem to like ocamlc as a straightforward compiler - if you write
code to do [x], the compiled code will also do [x], even if it can be
shown to be a no-op.

E.

Re: Ocaml back-end

[Sylvain Le Gall]

Hello,

On 06-12-2008, Gilles Pirio <gilles.ocaml@googlemail.com> wrote:
> (2) Any way to contribute this work back to Ocaml community (on a
> separate cvs branch?) or is this kind of work planned by the core
> Ocaml team?
>

To my mind, the best way is to provide a patch through the bug tracking
system of INRIA. This is highly probable that INRIA team doesn't accept
it directly but ask you to justify/modify it in order to fit the whole
compiler -- which could be quiet a long process in fact.

http://caml.inria.fr/mantis/

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: Ocaml back-end

[Gilles Pirio]

[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]

Hello
Ok, thanks for the feedback.

> To my mind, the best way is to provide a patch through the bug tracking
> system of INRIA. This is highly probable that INRIA team doesn't accept
> it directly but ask you to justify/modify it in order to fit the whole
> compiler -- which could be quiet a long process in fact.

It would greatly help to know what the INRIA team would consider as
acceptable ahead of doing the work. What kind of guidlines would you
advise me to follow? I guess I can add new passes but can I modify
existing ones?

The ideal solution would be to open the back-end using the dynlink
library. I've done it with 3.11 to speed up development. The back-end is now
a cmo file. I separately compile copt0.cmo, copt1.cmo... with different
back-ends. Then I can use command like: ocamlopt -copt copt0.cmo myfile.ml
to compile with my back-end.
But even though that's a small change I'm not sure the INRIA guys would
like it, right?


> Well, I can give you access to an unofficial public git mirror of
> INRIA's cvs.  I use it to build my compiler, but I dunno if anyone else
> uses it.  If it had optimizations like this, they might very well.

That sounds great, thanks. I'll follow up when I have the need to do that
(e.g. when
I get the above info and actually start the work).

Cheers
G<>



On Sun, Dec 7, 2008 at 9:58 PM, Sylvain Le Gall <sylvain@le-gall.net> wrote:

> Hello,
>
> On 06-12-2008, Gilles Pirio <gilles.ocaml@googlemail.com> wrote:
> > (2) Any way to contribute this work back to Ocaml community (on a
> > separate cvs branch?) or is this kind of work planned by the core
> > Ocaml team?
> >
>
> To my mind, the best way is to provide a patch through the bug tracking
> system of INRIA. This is highly probable that INRIA team doesn't accept
> it directly but ask you to justify/modify it in order to fit the whole
> compiler -- which could be quiet a long process in fact.
>
> http://caml.inria.fr/mantis/
>
> Regards,
> Sylvain Le Gall
>
> _______________________________________________
> 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
>

[-- Attachment #2: Type: text/html, Size: 3231 bytes --]

Re: Ocaml back-end

[Sylvain Le Gall]

On 09-12-2008, Gilles Pirio <gilles.pirio@gmail.com> wrote:
>> To my mind, the best way is to provide a patch through the bug tracking
>> system of INRIA. This is highly probable that INRIA team doesn't accept
>> it directly but ask you to justify/modify it in order to fit the whole
>> compiler -- which could be quiet a long process in fact.
>
> It would greatly help to know what the INRIA team would consider as
> acceptable ahead of doing the work. What kind of guidlines would you
> advise me to follow? I guess I can add new passes but can I modify
> existing ones?
>
> The ideal solution would be to open the back-end using the dynlink
> library. I've done it with 3.11 to speed up development. The back-end is now
> a cmo file. I separately compile copt0.cmo, copt1.cmo... with different
> back-ends. Then I can use command like: ocamlopt -copt copt0.cmo myfile.ml
> to compile with my back-end.
> But even though that's a small change I'm not sure the INRIA guys would
> like it, right?
>
>

This idea rocks! The best way is to begin by providing a basic patch and
follow this explanation:
http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/
(even if it is not said, half of the people involved are OCaml
developers).

The other idea is that the smallest is the best. That's why your idea
rocks. If the possibility to dynamically load backend is small, it will
be a very good first step.

When you will have made this first step (that can profit to all), you
can either submit your backend or provide it by any other mean.

Regards
Sylvain Le Gall

ps: consider fecthing a copy of the CVS 
http://camlcvs.inria.fr/

Re: [Caml-list] Re: Ocaml back-end

[Gilles Pirio]

[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]

Greetings all..

Following up on an idea explored few weeks ago, I've now implemented the
dynamic back-end mechanism on ocamlopt.

What would be the way to go for ocamlopt.opt? I don't think we want to have
this dynamic back-end thingie with opt.opt as native dynlink isn't supported
on all platforms. My approach at the momemt is to have different files for
the back-end loader (depending on whether it is an opt or opt.opt build). So
the makefile is a bit messier than before. Would that be ok anyway, any
better way to do that that I'm not aware of? If this is fine, I'll submit my
patch.

Cheers
Gilles



On Tue, Dec 9, 2008 at 7:31 PM, Sylvain Le Gall <sylvain@le-gall.net> wrote:

> On 09-12-2008, Gilles Pirio <gilles.pirio@gmail.com> wrote:
> >> To my mind, the best way is to provide a patch through the bug tracking
> >> system of INRIA. This is highly probable that INRIA team doesn't accept
> >> it directly but ask you to justify/modify it in order to fit the whole
> >> compiler -- which could be quiet a long process in fact.
> >
> > It would greatly help to know what the INRIA team would consider as
> > acceptable ahead of doing the work. What kind of guidlines would you
> > advise me to follow? I guess I can add new passes but can I modify
> > existing ones?
> >
> > The ideal solution would be to open the back-end using the dynlink
> > library. I've done it with 3.11 to speed up development. The back-end is
> now
> > a cmo file. I separately compile copt0.cmo, copt1.cmo... with different
> > back-ends. Then I can use command like: ocamlopt -copt copt0.cmo
> myfile.ml
> > to compile with my back-end.
> > But even though that's a small change I'm not sure the INRIA guys would
> > like it, right?
> >
> >
>
> This idea rocks! The best way is to begin by providing a basic patch and
> follow this explanation:
> http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/<http://et.redhat.com/%7Erjones/how-to-supply-code-to-open-source-projects/>
> (even if it is not said, half of the people involved are OCaml
> developers).
>
> The other idea is that the smallest is the best. That's why your idea
> rocks. If the possibility to dynamically load backend is small, it will
> be a very good first step.
>
> When you will have made this first step (that can profit to all), you
> can either submit your backend or provide it by any other mean.
>
> Regards
> Sylvain Le Gall
>
> ps: consider fecthing a copy of the CVS
> http://camlcvs.inria.fr/
>
> _______________________________________________
> 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
>

[-- Attachment #2: Type: text/html, Size: 3855 bytes --]

Re: [Caml-list] Re: Ocaml back-end

[Sylvain Le Gall]

Hello,

On Tue, Jan 13, 2009 at 07:09:16PM +0000, Gilles Pirio wrote:
> Greetings all..
> 
> Following up on an idea explored few weeks ago, I've now implemented the
> dynamic back-end mechanism on ocamlopt.
> 
> What would be the way to go for ocamlopt.opt? I don't think we want to have
> this dynamic back-end thingie with opt.opt as native dynlink isn't supported on
> all platforms. My approach at the momemt is to have different files for the
> back-end loader (depending on whether it is an opt or opt.opt build). So the
> makefile is a bit messier than before. Would that be ok anyway, any better way
> to do that that I'm not aware of? If this is fine, I'll submit my patch.
> 

You can play a little bit with camlp4 and pa_macro to disable certain
part of your opt.opt (like replacing dynlink call by nothing/empty
list...).

I think you can try doing this kind of conditional compilation well
enough if your changes are located in an almost central place

> On Tue, Dec 9, 2008 at 7:31 PM, Sylvain Le Gall <sylvain@le-gall.net> wrote:
> 
>     On 09-12-2008, Gilles Pirio <gilles.pirio@gmail.com> wrote:
>     >> To my mind, the best way is to provide a patch through the bug tracking
>     >> system of INRIA. This is highly probable that INRIA team doesn't accept
>     >> it directly but ask you to justify/modify it in order to fit the whole
>     >> compiler -- which could be quiet a long process in fact.
>     >
>     > It would greatly help to know what the INRIA team would consider as
>     > acceptable ahead of doing the work. What kind of guidlines would you
>     > advise me to follow? I guess I can add new passes but can I modify
>     > existing ones?
>     >
>     > The ideal solution would be to open the back-end using the dynlink
>     > library. I've done it with 3.11 to speed up development. The back-end is
>     now
>     > a cmo file. I separately compile copt0.cmo, copt1.cmo... with different
>     > back-ends. Then I can use command like: ocamlopt -copt copt0.cmo
>     myfile.ml
>     > to compile with my back-end.
>     > But even though that's a small change I'm not sure the INRIA guys would
>     > like it, right?
>     >
>     >
> 
>     This idea rocks! The best way is to begin by providing a basic patch and
>     follow this explanation:
>     http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/
>     (even if it is not said, half of the people involved are OCaml
>     developers).
> 
>     The other idea is that the smallest is the best. That's why your idea
>     rocks. If the possibility to dynamically load backend is small, it will
>     be a very good first step.
> 
>     When you will have made this first step (that can profit to all), you
>     can either submit your backend or provide it by any other mean.
> 
>     Regards
>     Sylvain Le Gall
> 
>     ps: consider fecthing a copy of the CVS

Regards
Sylvain Le Gall