[m-rev.] [m-dev.] gh72 test failures at higher optimization levels

[Peter Wang]

On Mon, 25 Jan 2021 12:08:13 +1100 Peter Wang <novalazy at gmail.com> wrote:
> 
> The float regs pass (only runs on 32-bit platforms) fails on
> hard_coded/gh72 with
> Software Error: predicate `transform_hlds.float_regs.match_args'/12: Unexpected: length mismatch
> 
> I'm looking into it now.

The daio pass doesn't change the types and argument modes of
higher-order variables which would be bound to daio cloned procedures,
and the discrepancy between the number of arguments in a higher-order
type or inst, and the number of arguments in a call, confuses the
float_regs pass. No other parts of the compiler seem to have a problem
with this?

Here's what I *think* needs to change.
I've attached the output of this command:
mmc -s asm_fast.gc -O0 -d111 --dump-hlds-options vlDnia gh72.m

1. When a unification constructs a closure,
where some of the remaining arguments are daio argments,
the type of the closure variable currently does not reflect
the cloned daio argments.
The higher-order inst of the closure variable also does not reflect
the cloned daio argments.

e.g. in gh72.higher_order_tests the type of ClosureA_10
still has one argument

    % ClosureA_10 (number 10): (pred gh72.t)

and the inst in the unification mode/instmap delta also has one
argument. The variable is actually bound to a daio clone procedure
that takes two arguments:

    ClosureA_10 = gh72.direct_arg_in_out_0_fill1(StrA_6)
    % ClosureA_10 <= closure_cons<pred 944 proc 0> (StrA_6)
    % arg-modes in = in
    % cell_is_unique
    % new insts:
    %   ClosureA_10 -> /* unique */(pred(($typed_inst(gh72.t, (gh72.t234)) >> ground)) is det)


2. When producing a daio clone procedure, it may have a higher-order
argument which will be bound to a daio clone procedure.
The higher-order argument type currently does not reflect the daio
arguments; similarly for the higher-order inst.

e.g. in direct_arg_in_out_0_higher_order_test,
the type of the first argument Closure_5 has one argument:

    % Closure_5 (number 5): (pred gh72.t)

and the higher-order inst also has one argument:

    in((pred(($typed_inst(gh72.t, (gh72.t234)) >> ground)) is det))

but Closure_5 is actually called with two arguments:

    call(Closure_5, T_6, T_13)
    % new insts:
    %   T_6 -> clobbered(gh72.f1(clobbered) ; gh72.f2(clobbered) ; gh72.f3(clobbered) ; gh72.f4(clobbered))
    %   T_13 -> ground


Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gh72.hlds_dump.111-daio.gz
Type: application/gzip
Size: 17536 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20210125/d82337e5/attachment-0001.gz>