[m-users.] Stackoverflow from --intermodule-optimisation

Julien Fischer jfischer at opturion.com
Wed Sep 25 17:16:59 AEST 2013

On Wed, 25 Sep 2013, Paul Bone wrote:

> On Wed, Sep 25, 2013 at 04:49:04PM +1000, Michael Day wrote:
>> Hi Julien,
>>> IMO, such code should be re-written to avoid the stack overflow.
>>> Having your code rely on a particular optimization being enabled for
>>> completeness is a terribly brittle approache.
>> In that case there would be no point to have the optimisation at all, if
>> it is unsafe to write any code that could benefit from it.
>> This optimisation guarantees constant stack space for functions /
>> predicates that fit a certain syntactic pattern, just like regular
>> tail-call optimisation does.
>> Without these kinds of optimisations programming in Mercury would hardly
>> be feasible, and it would be impossible to write loops that used
>> constant-space. That's why I think they should be enabled by default,
>> and only disabled when testing the compiler: they are not really
>> optimisations, but essential features that make the language workable.
> Simon Taylor wrote to me off-list and proposed the following:
>    Having the time or space complexity of the program depend on
>    sophisticated optimisations often breaks the principal of least
>    surprise, but that can't always be avoided.
>    Tail recursion is an important special case. There could be a `:- pragma
>    tail_recursive(p/a)' declaration that causes a compile error or warning
>    if the predicate can't be made tail recursive.
> I responded saying that such a pragma could enable LCMC for the named
> predicate, without necessarily enabling it for the whole module.  This
> pragma should be exported in .opt files so that when the same code is
> compiled as part of another module LCMC can be performed there also.
> This may be a suitable comprimise.

I wouldn't do that until the following questions concerning the LCMC
optimisation can can be answered:

(1) Is LCMC causing performance degredation in some cases?  (Based on
comments in this thread, the answer seems to be yes.)

(2) If so, is the performance degredation significant and what is
causing it?

(3) Is the cause avoidable?


More information about the users mailing list