TRMC, reloaded #9760

Before this commit the representation of choices was type choice = | Return of lambda | Set of { direct: lambda; dps: Dps.t } the idea being that Return means that only the direct-style form is useful (there are no TMC calls, so never a need for a specific DPS implementation). The new representation has the same information encoded as a product rather than a sum: type choice = { direct: lambda; dps: dps.t; has_tmc_calls: bool; } When `has_tmc_calls` is false, this is the same as `Return`, otherwise it is a `Set`. This new representation makes some of the code easier (more homogeneous, no need for case distinctions), and it avoids some bugs we had when considering how to mix Return and Set values together.

These tests are less robust than the other TMC tests, but they test more varied aspect of the transformation, and will be useful to assess the impact of upcoming code changes during the code review period, and further improvements to the TMC transformation.

…ol]. The direct-style version of the tailmap3 function let[@tail_mod_cons] rec tailmap3 = fun f li -> match li with | [] -> [] | x :: xs -> f 0 x :: f 1 x :: f 2 x :: tailmap3 f xs looked as follows before this PR: (tailmap3/109 (function f/110 li/111 tail_mod_cons (if li/111 (let (xs/113 =a (field 1 li/111) x/112 =a (field 0 li/111)) (let (block/115 = (makemutable 0 (apply f/110 0 x/112) 0)) (seq (let (arg1/116 = (apply f/110 1 x/112) block/117 = (makemutable 0 (apply f/110 2 x/112) 0)) (seq (setfield_ptr(heap-init)_computed block/115 1 (makeblock 0 arg1/116 block/117)) (apply tailmap3_dps/114 block/117 1 f/110 xs/113))) block/115))) 0a)) It now looks as follows: (tailmap3/109 (function f/110 li/111 trmc (if li/111 (let (xs/113 =a (field 1 li/111) x/112 =a (field 0 li/111)) (makeblock 0 (apply f/110 0 x/112) (makeblock 0 (apply f/110 1 x/112) (let (block/115 = (makemutable 0 (apply f/110 2 x/112) 0)) (seq (apply tailmap3_dps/114 block/115 1 f/110 xs/113) block/115))))) The idea is that the deeply nested constructor (f 2 x :: ...) needs to be turned into a location for the tailmap3 call to go to the DPS version, but the code around this constructor itself does not need to be put in DPS form (as the constructor is already providing a location). Advertising that it "does not benefit from DPS" let us generate the much nicer version below, by not trying to create new locations on each constructor above it.

@tailcall

One reason to error in these ambiguous situations, instead of making a choice for the user, is that the TMC transformation changes the evaluation order, delaying the call that is made tailrec to after the evaluation of all other arguments. Example: ``` type 'a tree = | Leaf of 'a | Node of 'a tree * 'a tree let[@tail_mod_cons] rec correct_map f = function | Leaf v -> Leaf (f v) | Node (left, right) -> Node (correct_map f left, (correct_map[@tailcall]) f right) let[@tail_mod_cons] rec incorrect_map f = function | Leaf v -> Leaf (f v) | Node (left, right) -> Node (incorrect_map f left, incorrect_map f right) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error: [@tail_mod_cons]: this constructor application may be optimized in several different ways, please disambiguate by adding a [@tailcall] attribute to the call that should be made tail-recursive. ```

We need to use this logic in lambda/tmc.ml to support tupled functions.

Partial applications are obviously not considered TMC calls, but this is also the case for direct calls to Tupled functions that do not take a direct tuple literal, but another tuple value.

There is a naming conflict between using 'return v' to mean - "build a piece of code that returns the same result as `v`", and - the `return` function of the applicative functor (Note that the first operation is not polymorphic: it has type lambda -> lambda t and not 'a -> 'a t ) To avoid this ambiguity we rename our 'return' functions into 'lambda'. (Issue spotted by Pierre Chambart during review.)

(suggestion from Konstantin Romanov) After discussion with Pierre Chambart, we convinced ourselves that the tagged forms is what users will see in their debugger, and went for 0xBBBB / 2, which gets tagged as 0xBBBB. Co-Authored-By: Pierre Chambart

Co-Authored-By: Pierre Chambart

(suggestion from Konstantin Romanov)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TRMC, reloaded #9760

TRMC, reloaded #9760

Commits on Nov 2, 2021