[m-dev.] for review: --dead-code

[Zoltan Somogyi]

On 21-Jul-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > I don't like that name; in most ways this operation has nothing to do with
> > lazyness.
> 
> Why do you say that?
> 
> The transformation delays doing work, and where possible avoids doing
> the work altogether.  That sounds like laziness to me.

I agree on that part, however ...

> The main
> difference from standard lazy evaluation are that the decision
> as to whether something will be needed is made at compile time,
> and is thus necessarily more conservative.

.. in my view, this conservatism means that you don't get any of the
guarantees that lazyness gives you. OTOH, you don't have to pay any
of the overheads of lazyness either. In my view, these two things are
what people think of when you mention lazyness. Overall, I think including
lazyness in the name would cause unnecessary confusion.

In any case, many other optimizations (e.g. constraint propagation) could
also be described as "where possible avoids doing the work altogether".

> Note that this transformation is doing exactly the same thing as the
> `--lazy-code' option in the current LLDS code generator.

It isn't doing the *same* thing; it is doing something significantly more
general, at least if the semantic switches let it. And even with the most
conservative semantics, it can move construction unifications across compound
goals and across calls, which --lazy-code cannot.

> Actually I think this optimization may be closely related to one
> called "lazy code motion", which is implemented in recent
> versions of gcc.  I found a PLDI paper on that on the web;
> there's a copy in ~fjh/papers/optimization/lazy_code_motion.pdf
> if you're interested.  (I haven't read it yet.)

I would not be surprised. As I said, optimizations related to this have been
standard in optimizing compilers for imperative languages for years.

I wanted to have a look at that paper, but I can't read it on screen, and
converting it to postscript with acroread generates a 189 Mb .ps file :-(,
which means it is too big to be printed. Anyone know a non-brain-damaged
pdf-to-ps converter?

> "Redundant" makes it sound like the code is doing work which is
> unnecessary because the work has already been done.
> But in this case, the work is simply unnecessary because it
> produces something which won't be used.

Well, to me "redundant" covers the second case as well as the first.
However, I am open to further suggestions.

> That's a good reason why the optimization should not be enabled
> by default at any optimization level.  But I don't see why that
> is a good reason to leave the option undocumented.

OK. I will document it, but only after we agree on an option name :-)

> Hmm... we should carefully check all the callers of
> code_aux__goal_cannot_loop, because many of them
> (e.g. the calls in rl.m and simplify.m)
> should call code_aux__goal_cannot_loop_or_throw.
> 
> (That could be done as a separate change.)

Exactly what I planned.

> > > ... since the implementation uses `inst_matches_binding',
> > > which ignores uniqueness, and which fails for `any' insts.
> > 
> > What is the correct test then?
> 
> Well, that depends on what it is you're trying to test.
> I don't yet understand what this code is trying to achieve.

I am trying to find out which variables have been further instantiated.
This means that I am trying to ignore differences between their initial
and final inst wrt inst names, wrt uniqueness, and wrt knowledge of what
functors parts of the variable are bound to.

Surely a predicate for checking this must already exist.

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------