[m-rev.] for review: merge successive switches on the same variable

[Zoltan Somogyi]

On 2023-08-17 09:18 +02:00 CEST, "Peter Wang" <novalazy at gmail.com> wrote:
> On Wed, 16 Aug 2023 03:30:58 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> +    % Since execution cannot reach the end of that combined arm,
>> +    % and since all the combined arms whose ends *can* be reached are det,
>> +    % the determinism of the merged switch is actually det.
> 
> But execution can fail before the end of the combined arm,
> so the merged switch *should* be semidet?

Yes, you are right; that situation is not an exampe of a too-conservative
determinism. So I replaced it with another, which has the same two switches
in the opposite order, so the one arm in each switch that is not det
now occur in the combined arm as an <erroneous,semidet> pair,
instead of a <semidet, erroneous> pair.

>> +    % It does not matter whether we take FirstGoalInfo or SecondGoalInfo
>> +    % as the basis for GoalInfo, because we explicitly set up all of
>> +    % the fields that the 
> 
> The sentence is incomplete.

Very incomplete. I replaced it with

    % It does not matter whether we take FirstGoalInfo or SecondGoalInfo
    % as the basis for GoalInfo, because we explicitly set up all of
    % the fields that the rest of the compiler invocation can pay attention to.
    %
    % - The egi_context field is not used by the rest of the simplification
    %   pass, because it belongs to a compound goal (either a merged
    %   conjunction or a merged switch) that we don't generate warnings for.
    %   And all the compiler passes after the first invocation of
    %   simplification that generate error or warning messages do so for
    %   for either procedures or calls to procedures, not compound goals.
    %
    % - The gi_goal_id and egi_rev_goal_path fields are considered valid
    %   only bwtween a pass that fills them in, and the next pass that
    %   can make any changes to the procedure's body goal. Simplification
    %   can make changes, so it would invalidate those fields even if
    %   we did merge switches.
    %
    % - The egi_goal_mode and egi_maybe_mode_constr field are not yet used.
    %
    % - The gi_code_gen_info field is used only by the LLDS backend,
    %   It is filled in only after the last invocation of simplification.
    %
    % - the egi_ho_value_map field is filled in by the closure analysis pass,
    %   and read by the exception analysis and termination passes. There are
    %   no invocations of the simplification pass between those passes.
    %
    % - the egi_maybe_ctgc, egi_maybe_rbmm and egi_maybe_dp fields
    %   are used only within their respective passes, and are not meaningful
    %   outside those passes.

> The rest looks okay, I think.

Thanks. I followed your other suggestions.

> I'd be interested if you have any measurements.

No, I don't. There are only about half a dozen cases in the compiler
where this transform's preconditions are met, and none are performance
critical. If two switches on the same variable were ever performance critical,
the programmer would have probably merged them manually. I wrote this code
to remove the need to do so. The reason why I wrote it now is because I want
to rewrite the code of module_name_to_file_name_ext, which now contains
one switch that computes three things (the directory path, the base file name
before the extension string, and the extension string) with three separate switches
computing those things individually, and don't want to worry about any
performance loss caused by that.

The reason why I want to split the switch is that when doing filename translations
when writing to files containing mmakefile fragments, usually we do so by translating
many module names to filenames with the SAME extension. This should allow the
computation of the directory path and the extension string to be done just once,
while the conversion of the module name to the base name has to be done for
each module name. This requires file_names.m to export operations that each return
just one of those three components.

Zoltan.