Extended static exceptions for 4.05

[chambart]

This branch is an update of #98 for 4.04

This only contains the part about extending the Cmm Ccatch construction to allow recursive cases and the handling in further backend passes.

As noted by @xavierleroy in the other pull request, the name of this construction should change, but for patch maintanability, I'd prefer to do that in a separate patch if this one is accepted.

I didn't change it yet, but I'd like to require a rec annotation for recursive cases. Mainly for being more explicit and allow to be a bit faster in the passes that needs to reach a fixpoint in the recursive case.

Notice that now, registers are a bit more typed. Currently this patch only accept registers of type val as arguments (as before), but we might need to put anything in there (in particular values built with Ctuple). There are multiple possibilities to do that, but I don't want to finish implementing any before having received some feedback on what would be prefered.

• Do the typing on Cmm. The drawback being that it almost requires to duplicates large parts of selectgen to propagate the same types everywhere.
• Do the typing on Mach. I find that quite inelegant as this would require to either duplicate the mach to have a special version for 'typing' containing type variables, or change the Cmm.machtype to allow some type variable register (and pollute every pass with that).
• Requite a type annotation on Ccatch like for function argument and application. (This is the solution I prefer) The drawback would be obviously that this requires a bit more work for the pass generating it (currently the transformation patch would obviously be just adding the Val annotation everywhere).

Note that for testing purpose I extended a bit the cmm parser to accept actual output of -dcmm and be a bit more convenient.

Nothing except the backend change is provided here, in particular, the generated code won't benefit for any optimisation yet. There is a small difference in the output of Selectgen as recursive cases might require an additionnal register move (as shown in the following swap example). When this is not required, the register allocator should coalesce the intermediate temporary registers and the generated code shouldn't differ.

(function swap (n : int a : val b : val)
  (catch (exit swap n a b)
   with (swap n a b)
     (if (<= n 0)
         a
         (exit swap (- n 1) b a))))

swap:
.L102:
    movq    %rax, %rsi
    movq    %rbx, %rax
.L100:
    cmpq    $0, %rsi
    jg          .L101
    ret
.L101:
    decq    %rsi
    movq    %rax, %rbx
    movq    %rdi, %rax
    movq    %rbx, %rdi
    jmp     .L100

The first thing to do after a potential merge of this is a cleanup: rename the constructors, remove the Cloop construction, then propagate those constructions up to flambda.

[chambart]

Rebased on latest trunk.

[lpw25]

the name of this construction should change

This is pure bikeshedding, but I would suggest something like let_cont (for let continuation). Or possibly if the order is kept so that the continuation definition comes after its scope where_cont like the where construct in Haskell.

[mshinwell]

(I am going to review this GPR in detail)

[mshinwell]

We decided to leave the name change until later.

I've reviewed this carefully and discussed the details with Pierre. I have pushed code review comments to the recursive_static_exceptions branch on my Github account. Once Pierre attends to these, which are generally fairly minor things, I think this is OK to merge.

@xavierleroy Are you happy with this?

[chambart]

The changed discussed have been made.

Also rebased.

[chambart]

I forgot to push an update of the testsuite parser, here it is.

By the way, the travis CI rightfully failed, but not appveyor. Is it not running the testsuite ?
the build was: https://ci.appveyor.com/project/avsm/ocaml/build/1.0.685

Apparently it is skipping the asmcomp part of the testsuite. Is there any reason for that ?

[mshinwell]

@chambart Can we get this into trunk?

[lefessan]

No, it's not mergeable, there are conflicts that must be resolved...

[chambart]

This is now rebased on current trunk. The main conflics where comming from spacetime integration.

[chambart]

Rebased again against lastest trunk (cmm debuginfo conflicts mainly).

This branch clearly wins the title of my most rebased branche.

[mshinwell]

I believe this is ok for 4.05 following previous discussions and code review.
I have also tested it recently by compiling "for" and "while" using recursive static exception handlers with no problems apparent.