Comment author: @gasche

I could reproduce the issue.

You need -O3 for the optimization to kick in, -O2 is not enough.

4.06.1 also performs the expected optimization, so the regression is between 4.06 and 4.07.

Comment author: @gasche

Bisecting seems to indicate that the regression was introduced in

Flambda: Add [Closure_origin.t] to trace inlined functions (merged) (#1707)
#1707

Comment author: @lpw25

I haven't investigated in detail, but from the look of that code and the bisection, I would say that this is an expected regression. That commit is there to prevent the inliner getting into an infinite loop. It is difficult to tell the difference between the code in this example and code that causes an infinite loop.

I have a branch -- worked on in succession by two interns -- that rewrites how the inlining heuristics and limits work so that they have a predictable semantics. This branch should work properly on this kind of example, but it won't be ready until OCaml 4.09.

Comment author: @lpw25

That commit is there to prevent the inliner getting into an infinite loop

I should clarify this part before someone suggests using a timer or a big counter.

That commit adjusts how we detect recursive function calls. Flambda's current semantics are supposed to limit the depth of recursive function calls to the (IIRC) "unrolling-depth" and there were cases before 4.07 where we would fail to detect the recursion. So the bug was that the unrolling depth was being ignored -- as a symptom of this bug we could also get infinite loops.

In this code, there are patterns which look like recursion to the recursion detection and so they are being artificially limited by the unrolling depth.

Comment author: @damiendoligez

So the solution would be to use the -inline-max-unroll command-line option described in http://caml.inria.fr/pub/docs/manual-ocaml/flambda.html#speculation right?

Comment author: @lpw25

Possibly, although you might make things blow-up pretty quickly. I can't look at the example code right now due to a proxy (perhaps we should discourage using pastebin for reproduction cases), but IIRC it had genuine recursive calls mixed up with higher-order calls that look recursive to flambda. If you change the max unroll count then you're going to inline both of those cases. Same goes for annotating the calls with [@unroll n].

We have decided that the improved tracking of recursion with respect to inlining will only be implemented for Flambda 2.0. We will check the behaviour with this example, but we don't need to keep this issue open, as it appears to be an expected regression in the current compiler.