[m-dev.] proposals for improving the situation wrt Mantis bug #585

[Peter Wang]

On Fri, 18 Sep 2026 22:58:38 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> The proposals are attached for your perusal and opinions.
> 
> Zoltan.

> ----------------------------------------------------------------------
> 
> My first proposal is therefore that
> 
> - when two or more branches of a branched control structure (e.g. B1 and B3)
>   use isomorphic typeclass_info structures but refer to it using different
>   variables (as TypeClassInfo_for_uenum_{21,30} above), and
> 
> - the code that occurs to the right of the branched structure,
>   such as fragment C, references none of those typeclass info variables,
> 
> then we should simply choose one of those variables, such as
> TypeClassInfo_for_uenum_21, and simply REPLACE the variables
> in the other branches that hold the isomorphic typeclass infos
> with this chosen variable. (The replacement would happen in the
> rtti_varmaps as well as in the procedure body goal.)
> 
> This eliminates the Mantis 585 problem, as exhibited by this e.g. switch,
> at a stroke. (A clash between the chosen typeclass info variable
> and some other typeclass info variable for the same constraint *outside*
> the switch will remain.) Not only will the same typeclassinfo variable
> represent the constraint in all the branches where that constraint is relevant,
> but that variable'a compiler-allocated stack slot is where the typeclass_info
> for that constraint will be stored while the program is executing in each of
> those branches. And the debugger will find the typeclass_info in that
> stack slot in each branch where it needs that typeclass_info.
> 
> However, it must be noted that this solution is fragile. because
> any rerun of quantification will undo our renaming. Since each typeclass
> info is local to its own branch, they can be variables local to each branch,
> and quantification will rename apart to ensure this. We therefore
> have to do something to prevent that.
> 
> One way would be to add a dummy consumer of the chosen typeclass info var.
> However, since simplification can eliminate a det call that does not
> compute anything, this just trades one form of fragility for another.

But telling simplification not to remove the dummy consumer would be
easy.

> 
> Another is to simply to do this renaming just before code generation,
> *after* the last time quantification is run on the procedure body.
> 
> A third way would be to simply gather the set of chosen typeclass info vars,
> and tell quantification in some way "do not rename these variables apart".
> One possible mechanismfor this would be a new kind of scope wrapped around
> the procedure body.

> ----------------------------------------------------------------------
> 
> My second proposal is for situations where the second of the two conditions
> of the first proposal does not hold. Therefore it applies when
> 
> - when two or more branches of a branched control structure (e.g. B1 and B3)
>   construct isomorphic typeclass_info structures but refer to it
>   using different variables (as TypeClassInfo_for_uenum_{21,30} above), and
> 
> - the code that occurs to the right of the branched structure,
>   such as fragment C, DOES reference one of those typeclass info variables,
> 
> (If it references two or more, then either recursive application of these
> techniques, starting at inner branched control structures and moving outward,
> can reduce these references to one, or it cannot. In the latter case,
> the proposal will not fix the Mantis 585 issue, and we can only report it.)
> 
> In such situations
> 
> - we can choose the typeclass info variable that occurs after the branched
>   control structure to represent the constraint inside the relevant branches
>   as well, and then,
> 
> to ensure that the branched control structure defines a typeclass info
> for the constraint regardless of which branch is executed,
> 
> - either copy the code to construct that typeclass info variable from its
>   "home" branch to all the other branches that (in their original form)
>   do not define such a typeclass info (if there are any), or
> 
> - delete that code from all the branches that have it, and put just one copy
>   to just before the start of the branched control structure. It does not
>   matter which, since they are isomorphic, and by assumption, the inputs
>   to the computation of typeclass into construction process are all either
>   constants, or variables that were already ground at that program point.
> 
> The latter is probably preferable in terms of code size, though it may
> increase stack slot pressure.
> 

The latter sounds preferable.

The proposal seems good to me.

Peter