[m-dev.] proposal: remove hlc_nest and hl_nest grades

[Julien Fischer]

Hi Zoltan,

On Tue, 14 Nov 2017, Zoltan Somogyi wrote:

> On Thu, 31 Aug 2017 14:13:25 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>>> If not, and if we *do* delete the hlc_nest grades, then we should
>>> simplify the MLDS backend. At the moment, we always generate MLDS code
>>> with nested functions, which ml_elim_nested.m then hoists out. Having
>>> the code generator generate the functions in their non-nested form
>>> directly would be simpler and faster, partly because it wouldn't have
>>> to cater to ml_elim_nested.m's limitations.
>>
>> That's one of the reasons I suggested removing them.  In fact, IIRC
>> ml_elim_nested.m is actually a bit of a performance bottleneck on
>> large programs.
>
> I have been thinking about generating flattened MLDS code directly, not
> via ml_elim_nested.m. It looks to be far from easy, and I just measured
> ml_elim_nested as taking about 1% of the compiler's runtime on tools/speedtest.
> At that rate, that change does not seem to be all that worthwhile. Do you,
> or anyone else, have some test cases for which the compiler takes substantially
> longer in ml_elim_nested.m?

Not currently from the looks of it.   What I was referring to above was
based on the compilation times of code generated by the Zinc compiler a
number of years ago.  The current version of the Zinc compiler now
generates different code and doesn't appear to have any issues with the
elimination of nested functions.  (I will have a dig about and see if I
can find something, but don't hold your breath on that ...)

Julien.