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

[Peter Wang]

On Mon, 25 Jan 2021 18:28:48 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 2021-01-25 17:25 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
> >> I'm looking into it now.
> 
> Thanks for that.
> 
> > 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?
> 
> Given that on my laptop, a bootcheck passes with -O5 --intermodule-opt,
> it seems not.
> 
> > 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
> 
> I think you are right, but I have to ask: if it affects only (a) code with daio
> args (b) on 32 bit systems, a combination of two rare circumstances,
> is a fix it worth it? Or could we get by with just a sorry, not implemented
> message if we find any daio args on 32 bit systems. Opinions?

I don't mind if that combination doesn't work.

We can also consider removing the float registers support now.
I can't think of a case for running on 32-bit platforms AND using the
low-level C grades any more. Low-level C grades would still work anyway.

I don't like the idea of leaving the HLDS in an inconsistent state,
even if it's limited to daio clones. I might take another look at
fixing it.

Peter