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

[Zoltan Somogyi]

On Tue, 14 Nov 2017 01:29:04 -0500 (EST), Julien Fischer <jfischer at opturion.com> wrote:

> 
> 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.

Yes, I remember that. I made a significant number of changes to eliminate
all the bottlenecks that made the compiler so slow in compiling Mercury code
generated from Zinc.

> 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.

Given all those changes about 8-10 years ago, the former is not *necessarily*
the cause of the latter :-)

Zoltan.