[m-rev.] for review: rationalise simplify_goal_call.m

[Peter Wang]

On Mon, 22 Dec 2014 17:27:46 +1100 (EST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> I am doing this as cleanup before working on strength reduction
> for divisions and shifts. Since it touches so much of simplify_goal_call.m,
> I am attaching the updated version of that file.
> 
> For review by anyone, but since I would like to build on this soon,
> I intend to commit it if noone reviews it in the next couple of days.

I'll mention it: a great advantage of distributed version control is
that you can commit locally and continue working.

> 
> BTW, I noticed that the simplify_goal_call.m has two related transformations
> that almost work at cross purposes.
> 
> - The first replaced calls such as @<(X, Y) with compare(R, X, Y), R = (<).
> - The second replaced calls such as compare(R, X, Y) with
> 
>   if builtin_compound_eq(X, Y) then R = (=) else
>   if builtin_compound_lt(X, Y) then R = (<) else R = (>)
> 
>   but only on the Erlang backend, since that is the only one
>   that has builtins for comparing entire structured terms.
> 
> The first yields a speedup on non-Erlang platforms because it inlines
> the definition of @< (which itself does compare(R, X, Y), R = (<)),
> and the second yields a speedup on Erlang because (I presume)
> it eliminates a whole lot of crossings of the Mercury/Erlang boundary.

Judging by my commit message, the reason was to avoid the overhead of
the bytecode interpreter.

> 
> However, the first transformation is a PESSIMIZATION for Erlang.
> The obvious thing to do on that platform is to replace @<(X, Y) with builtin_compound_lt(X, Y). (NOTE: I think the bad structure of
> simplify_goal_call.m up to now is probably why noone has noticed
> the problem until now.)
> 
> Peter, since I think you know the Erlang backend best: do you think
> such a change would be useful, and if so, if I implement it, will you
> test it? (I cannot test it myself.)

Your time is better spent on other things.  My hunches are that:

  1. no one is using the Erlang backend seriously
  2. @< et al are rarely used
  3. an extra builtin equality test is a relatively minor expense
     on that backend

Peter