[m-users.] accumulator introduction in HLC

[Zoltan Somogyi]

On Tue, 09 Jun 2015 15:03:37 +0100, matthias.guedemann at googlemail.com (Matthias Güdemann) wrote:
> 
> When using the function for lists of size 400000 or so, this produces
> the above error, when compiling using 'mmc -mrH', adding
> '--introduce-accumulators' to the compile options does not change the
> outcome.
> 
> Compiling in 'asm.fast.gc' works with and without the
> '--introduce-accumulators' option; using the predicate version of
> 'get_range' works in both grades.
> 
> What is the problem here? Shouldn't '--introduce-accumulators' take care
> of this?

Maybe it should, but at the moment, the optimization you are after
is controlled by the --optimize-constructor-last-call option. Specifying
--introduce-accumulators does not change either the function or the predicate
version in either hlc or asm_fast grades, so none of them are proof against
stack overflows; the hlc version just happens to run out stack earlier.

The --introduce accumulators and --optimize-constructor-last-call options
are separate both because the implementations are totally separate
(there are some similarities, but there are many more differences),
and because the extra argument added to the newly created auxiliary procedure
by --optimize-constructor-last-call is the address of a memory cell to be
filled in, not an accumulator. Accumulators record the result of a series
of operations performed so far; addresses to be filled in don't qualify.

That being said, maybe we should explore the idea of adding options that
turn on not just one optimization, but a family of related optimizations.

Zoltan.