I tried to lift the optimization to Translcore, i.e. the mapping from Typedtree to Lambda. (I do not believe the "static jumps" should be represented in Typedtree if they are not exposed in the surface syntax.) It became a bit hairy (actually, I did not achieve to finish it), and introduced backtracking in this pass.

Yes, the current approach is a bit fragile, but we have the attribute to check that the optimization is not discarded. In most cases, the optim will be triggered by rather simple exception patterns (not mixing static and non-static ones), and it's easy to ensure this is not broken through non regression tests with the attribute.

The advantage of the current approach is that it preserves the "direct" mapping from Typedtree to Lambda and pushes the optimization to where it belongs, i.e. further down in the compiler. There are currently not so many optimization implemented in the Typedtree to Lambda pass. It could be interesting to have it done even later, post inlining, but this would make it unavailable to bytecode and derived backends (buckescript/js_of_ocaml).

One part that is not very satisfying in the current proposal is the way the attribute is propagated. A cleaner way could be to annotate the Llet nodes, but doing this just for that case seems a bit heavy. (Someone proposed to use "bitfields" for such cases, so that we don't have to rely on "stringly" typed attributes and still avoid introducing too much overhead for each such flag.)

We could use some opinions, e.g. that of @chambart . Even the author of this PR sounds "not very satisfied" by it, so in the absence of strong support it will be closed.

Personally, I agree with the general idea (we have static raise, so why not use it to optimize raise operations?), but I find the optimization too specific to be really useful. I mean, one has to declare a specially-annotated local exception, then write one's code so that the optimization triggers. It's not much less work than biting the bullet and rewriting the code not to use exceptions.

I mean, one has to declare a specially-annotated local exception

The local exception does not need to be specially annotated. You can annotate it if you want to be sure that the compiler will compile it as a local exception or fail otherwise, but the annotation is not required to trigger the optimization.

Even the author of this PR sounds "not very satisfied"

I mentioned that I'm specifically not satisfied with the plumbing for the annotation. One could rather improve it or just drop support for the annotation altogether (we survived for years without an attribute to assert that a call is compiled as a tail-call; and we don't have an attribute to assert that a local reference is compiled as a mutable variable).

It's not much less work than biting the bullet and rewriting the code not to use exceptions.

The goal is not so much to optimize exceptions than to expose the "static jump" control flow feature. How would you in general rewrite the code to avoid local exceptions?

Conclusion from today's caml-dev meeting: let's wait for typed effects and flambda to detect and optimize local exceptions.

It's not much less work than biting the bullet and rewriting the code not to use exceptions.

This is usually possible when the "raise" is in tail position, in which case raising can be turned into a tail-call to a local function. I've opened #2143 to deal with such cases of local functions directly.