[m-rev.] for review: direct_arg_in_out

[Peter Wang]

On Mon, 04 Jan 2021 21:13:49 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 2021-01-04 18:17 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
> > Do we have a test where the merged variable is used after a branching goal?
> 
> Not yet. While I add tests for this and ...
> 
> > It might be worth adding a test involving if-then-else.
> 
> ... for this, you might want to review the attached addition to the start-of-module
> comment, describing the reasons for choosing not to modify the code generators.

> % Since the problem is that instantations of such partial terms
> % are not visible in the caller, the solution is to *make* them visible
> % in the caller.
> %
> % One possible way to do that would be to modify the LLDS and MLDS code
> % generators to pass such arguments not by value, but by value-result.
> % (In Ada terms, this would mean treating them not as "in" arguments,
> % but as "in-out" arguments.) The other way to do it is via a program
> % transformation that replaces each such argument with a pair of arguments,
> % one input, and one output, arranging that after each call, all uses
> % of the passed input variable are replaced by the corresponding output
> % variable.
> %
> % This module solves the problem via the transformation approach.
> % I (zs) has several reasons for preferring this approach.

have

> %
> % The first reason is the obvious one: the code generator approach requires
> % modifying two backends, while one transformation works for all backends.
> %
> % The second reason is separation of concerns. The code in this module
> % implementing the transformation has to worry *only* about solving this
> % problem, while respecting the HLDS invariants, of course. Any modifications
> % to the code generators would have to worry about interactions between
> % this concern and all the other things that code generators have to
> % manage (such as stack slot allocation in the LLDS backend), while also
> % respecting the usual invariants of the code generators. I worry that
> % inanticipated interactions with the existing concerns would be
> % a lingering source of bugs in the future.

unanticipated

That's fine, thanks.

Peter