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

[Fergus Henderson]

On 21-Jul-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 20-Jul-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > This transformation is more like a static version of lazy evaluation.
> > Perhaps `--semi-lazy-code'?
> 
> 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.  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.

Note that this transformation is doing exactly the same thing as the
`--lazy-code' option in the current LLDS code generator.  I think
`--lazy-code' is a little misleading because 

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.)

> How about --eliminate-redundancies? Or --redundant-code?

Hmm; better than "dead code", but that still doesn't sound quite right.
"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.

> I can handle this by introducing a new integer option, perhaps called
> --eliminate-redundancies-copy-limit, and not copying a goal to more places
> than the value of this option.

Sounds good.

> > (If there is some reason why the documentation should not be
> > exposed to users yet, the documentation should still be added,
> > commented out, together with an explanation of why it is commented out.)
> 
> The reason is the slowdown in tree234, as I said at the meeting.

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.

> > > +:- pred dead_code__cannot_diverge(hlds_goal::in) is semidet.
> > 
> > There's already a predicate code_aux__goal_cannot_loop
> > which does the same thing as this one, so you should
> > use that rather than duplicating the logic here.
> 
> Actually, code_aux__goal_cannot_loop was only documented to do the same
> thing as dead_code__cannot_diverge, but its code did not check for
> throwing exceptions. I have now added a new predicate, 
> code_aux__goal_cannot_loop_or_throw, that does this check,
> and deleted dead_code__cannot_diverge.

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.)

> > > +	proc_info_headvars(ProcInfo, HeadVars),
> > > +	proc_info_argmodes(ProcInfo, ArgModes),
> > > +	assoc_list__from_corresponding_lists(HeadVars, ArgModes, HeadVarModes),
> > > +	IsInstChanged = lambda([VarMode::in, Var::out] is semidet, (
> > > +		VarMode = Var - Mode,
> > > +		mode_get_insts(ModuleInfo, Mode, Inst1, Inst2),
> > > +		\+ inst_matches_binding(Inst1, Inst2, ModuleInfo)
> > 
> > ... 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.

But, if you want to test whether two insts are exactly the
same modulo expansion of inst names, you could use

	inst_are_identical(Inst1, Inst2, ModuleInfo) :- 
		inst_matches_final(Inst1, Inst2, ModuleInfo),
		inst_matches_final(Inst2, Inst1, ModuleInfo).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------