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

[Zoltan Somogyi]

On Thu, 31 Aug 2017 13:25:57 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> Are there any objections to removing support for the hlc_nest( and
> hl_nest* grades?  (i.e. high-level C with GCC nested functions).
>
> While they were (presuambly) useful in the past for evaluating various
> design decisions in the MLDS backend, they haven't been used (or even
> documented) for quite a while now.
> 
> Additionally, GCC's support for nested functions was a bit flakey last I
> looked, so I can't really see anyone ever wanting to use these grades in
> anger.

I haven't used them in anger at all; when I did use them, it was just to check
they still worked (a long time ago).

However, if they do work right now, it would be best to see how fast they are
compared to their non-nested versions. IF they are faster, and IF there is still
some prospect of gcc resolving the flakiness (about which I know nothing),
I would prefer not to delete them just yet. Otherwise ...

By the way, does anyone have a machine that is good for benchmarking?
I would do the test above, but my laptop does thermal throttling in a way
that is bad for timing repeatability. I have seen two successive runs of
the exact same task (in tools/speedtest) return times as different as 20s and 30s.
This means that to get any information, I need a lot of runs (to average out
the variability), and even then, the results I get are not very precise.

Do the Java and C# backends use nested functions? 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.

Zoltan.