[m-rev.] diff: add XXXs about unused typeinfo_liveness fields

[Julien Fischer]

Hi Zoltan,

On Sat, 16 May 2020, Zoltan Somogyi wrote:

> When mdb-style execution tracing is enabled, handle_options.m
> sets body_typeinfo_liveness to true, which is intended to signal
> to compiler transformations that they should leave typeinfo
> arguments in place even if seemingly unused, since the debugger
> (originally mdb) may need access to them for interpreting the
> values of non-typeinfo arguments. It seems that higher_order.m
> was written with the *intent* to obey this rule, but never actually
> got there, since it ignores both this option, and its own clumsy
> attempt to set flags that play the same role.
>
> I thought this could be the bug behind gh89, but it can't be
> the complete story, since this problem would have similar bad effects
> on mdb. On the other hand, I don't usually compile programs
> in (non-ssdb) debug grades at -O3, and I don't think most people
> do either, so maybe we just never noticed the same problem with
> mdb.

That isn't the issue for gh89.  The problem there is the predicate
get_stripped_headvars/5 from compiler/ssdebug.m and its action on the
predicate introduced by higher-order specialisation for array.foldl2.

The body of get_stripped_headvars/5 is:

     get_stripped_headvars(PredInfo, ProcInfo, FullHeadVars, HeadVars, ArgModes) :-
         PredArity = pred_info_orig_arity(PredInfo),
         proc_info_get_headvars(ProcInfo, FullHeadVars),
         proc_info_get_argmodes(ProcInfo, FullArgModes),
         list.length(FullHeadVars, NumHeadVars),
         % Strip off the extra type_info arguments inserted at the front by
         % polymorphism.m.
         NumToDrop = NumHeadVars - PredArity,
         list.det_drop(NumToDrop, FullHeadVars, HeadVars),
         list.det_drop(NumToDrop, FullArgModes, ArgModes).

The problem is that when higher-order constructs a specialised version
of array.foldl2 it has five arguments, since the closure is no longer
passed in, but when higher_order.m sets the orig_arity for that
specialised prediate it sets it to six (i.e. the original arity of the
non-specialise array.foldl2).  I'm not sure if higher_order.m doing that
is deliberate or just an oversight.  From there we end up with NumToDrop
being -1, which cause det_drop/3 to abort.

As I noted in github, the old pre-20.01 behaviour of det_drop/3 would
have allowed this to "work", although I doubt whatever resulted was
actually what would be have been intended.

>From a quick inspection of compiler/ssdebug.m it is almost completely
unaware of the actions of higher-order specialised, unused argument
specialisation or any optimisations that produce specialisations with
a modified argument list.

> In the meantime, until these XXXs are fixed, we could simply have
> handle_options.m set the option calling for higher order specialization
> to "no" in ssdb (and maybe debug) grades. Since you are set up for it,
> could you see if this fixes gh89?

Compiling with --no-optimize-higher-order fixes the problem; we should
disable the same set of optimizations that are disabled for mdb style
debugging (by default) for ssdb.

I'll look into doing this.  (Supporting something like --trace-optimized
for ssdb is a much larger chunk of work.)

Julien.