I think I identified the problem:

The code produced after ds2cps (before the failing cps2ds pass) is:

.lam Uf_54920 _54941: «2; %math.F (52, 11)»: ★ = {
    .Idx 2
};
.con _cps_54993 _54994::[_54998: «2; %math.F (52, 11)», _54996: .Cn .Idx 2]@(0:(.Idx 2)) = {
    .let _54999: .Idx 2 = %core.bitcast «2; %math.F (52, 11)» .Idx 2 _54998;
    _54996 _54999
};
.lam eta__54897 _55002: «2; %math.F (52, 11)»: .Idx 2 = {
    %direct.cps2ds_dep («2; %math.F (52, 11)», Uf_54920) _cps_54993 _55002
};
.lam eta__55004 _55005: «2; %math.F (52, 11)»: .Idx 2 = {
    %direct.cps2ds_dep («2; %math.F (52, 11)», Uf_54920) _cps_54993 _55005
};
.con .extern stuff ... = {
    ...
    .let _55110: %mem.M = %bug.map_reduce 1 ‹2; (4, (1, 2, 15, 15), (%math.F (52, 11), 0:(%math.F (52, 11)), 4607182418800017408:(%math.F (52, 11)), %math.abs (52, 11) 0, eta__54897, eta__55004))› apply_55089 (_55104#0:(.Idx 2), _55104#1:(.Idx 2), _55104#1:(.Idx 2));
    return_54864 _55110
};

(Side note: eta__54897 and eta__55004 look like they should be unified as equal.)

The call to _cps_54993 is now tackled by cps2ds.
This is done (similar to the fun stuff) by calling it in cps with continuations for the rest.
Therefore, the body of eta__55004 is replaced by _cps_54993 ....
This, however, results in the type error above.

The issue lies in the assumptions of the pass:
As direct style functions can not generate code, all functions should fall into three categories:

Lowered by ds2cps into a cps function (that is just wrapped into a cps2ds call at its old position)
statically resolvable
higher order function that ends in a cps function

eta__54897 is used a as higher order argument contradicting these assumptions.

cps2ds - wrong body type #222

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions