Re: [Caml-list] Closing the performance gap to C

[Pierre Chambart <pierre.chambart@ocamlpro.com>]

Le 21/12/2016 à 18:43, Alain Frisch a écrit :
> On 21/12/2016 17:56, Mark Shinwell wrote:
>> I agree with Gabriel, but, we are planning substantial work within
>> Flambda during the coming year to implement unboxing transformations
>> therein.  I do think we should spend a little time, before diving into
>> this particular issue, convincing ourselves that these two tracks of
>> work are going to be complementary rather than conflicting.
>
> Dealing with boxing/unboxing in flambda rather than keeping it at the
> cmm level certainly seems the way to go in the context of the flambda
> pipeline.  This will probably need to touch the definition of clambda
> (to bring it closer to cmm) and thus cmmgen.  Do you believe this is
> compatible with continuing sharing clambda and cmmgen between the
> flambda and non-flambda pipeline?  At some point, it might be more
> natural, or just required, to compile flambda directly to cmm without
> going through clambda.  What do you think?
>
> If the flambda pipeline targets cmm directly without going through
> clambda/cmmgen, the approach discussed here (for the non-flambda case)
> should not interact too much with the flambda version.  As far as I
> can tell, they would mostly share the plumbing required to pass more
> info from typedtree to lambda.
>
>
> Alain
>
The machinery to do that correctly could be certainly be shared I think.
The way I see it, is change
the semantics of the float related primitives at the clambda and flambda
level. This should represent
explicitly unboxed float manipulation. The Closure/Closure_conversion
(or Flambda_to_clambda for
a first patch that does not change how flambda works) passes would
rewrite them to be enclosed
by new box/unbox primitives.
For instance in Cmmgen this would look like:

 | Pmulfloat ->
    Cop(Cmulf, [transl env arg1; transl env arg2], dbg)

 | Pboxfloat ->
    box_float dbg (transl env arg)
 | Punboxfloat ->
    transl_unbox_float dbg env arg


Then on functions and direct calls at clambda level, like in my old
patch, annotate the calling
convention.

This should be sufficient for doing what was done in that patch without
degrading anything and still
allowing this to be implemented separately in flambda. Of course the
Typedtree to lambda type
annotation propagation can be shared without any problem. Updating the
patch for that will be a
be tedious, but simple.

If you don't like the idea of having primitives that does not mean
exactly the same thing at the
different stages of the compiler, introducing a new unboxed version of
each float primitives is
also possible (with its use forbidden in lambda). I would like at some
point to have a different type
for lambda primitives and clambda primitives. It might be the right time
to do that.

Also, there was a problem with the approach of that old patch that
bothered me. The function
argument unboxing decision had to guess whether an argument was going to
be used boxed
or not. If the guess is wrong you might end up allocating more than
without unboxing. Having the
annotation there explicitly allow to do the unboxing earlier and rely on
the annotation for the decision.

Notice that the transformation was not completely local as it had to
propagate across functions
which argument might be used unboxed. In particular, recursive functions
made it a bit complex.
This was the job of the added Specialisation module.
-- 
Pierre