[m-rev.] ssdb v1.0 fixed

[Zoltan Somogyi]

On 12-Dec-2007, Ian MacLarty <maclarty at csse.unimelb.edu.au> wrote:
> > > As I understand it, the transformed code is still valid Mercury, so
> > > there should at least be some optimisations that will work on it.
> > 
> > That depends on what you mean by "work". Most optimizations won't introduce
> > any bugs for the code generated by the ssdb transformation (so they "work"
> > in one sense), but as soon as they see the impurity annotations, most
> > optimizations will leave the code alone, which means they won't improve
> > the code at all (so they do *not* "work" in another sense).
> > 
> 
> Yes, *most* will leave the code alone, but maybe *some* (current or
> future) will make it faster.

One, the chances of that are remote. Most optimizations that could speed
up the ssdb-transformed code would either

- leave the trace intact, which means you could leave them switched on
  even if you do the ssdb transformation at the end, or
- involve inlining, and thus increase code size, which is the last thing
  an ssdb-transformed program needs.

Two, if it turns out that an optimization *can* speed up ssdb-transformed
code, the chances of finding a bug in it are significant, since the heyday
of adding such optimizations was before we added the notion of impurity to the
language.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------