[m-dev.] for review: --use-local-vars

Fergus Henderson fjh at cs.mu.OZ.AU
Fri Mar 9 03:14:00 AEDT 2001


On 08-Mar-2001, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> +++ use_local_vars.m	Wed Mar  7 13:45:54 2001
> +% File: use_local_vars.m
> +%
> +% Author: zs.
> +%
> +% This module transforms the sequence of instructions in a procedure body.

"LLDS" should occur somewhere in the first sentence, to make it immediately
clear to readers that this is part of the LLDS back-end.

For example, perhaps something like this:

	% This module is an LLDS->LLDS transformation that optimizes
	% the sequence of instructions in a procedure body.

> +% It looks for two patterns. The first is
> +%
> +%	<instruction that defines a fake register>
> +%	<instructions that use and possibly define the fake register>
> +%	<end of basic block, at which the fake register is not live>
> +%
> +% When it finds an occurrence of that pattern, it replaces all references to
> +% the fake register with a temporary, which the C compiler can then put into a
> +% real machine register.

It would help to explain what you mean by a "fake register" here,
and what you mean by a "temporary".

> +:- pred some_code_addr_is_not_label(list(code_addr)::in) is semidet.
> +
> +some_code_addr_is_not_label([CodeAddr | CodeAddrs]) :-
> +	(
> +		\+ CodeAddr = label(_Label)

I'd write that as
		CodeAddr \= label(_Label)

> +	% Substitute NewLval for OldLval in an instruction sequence
> +	% until we come an instruction that may define OldLval.
> +	% We don't worry about instructions that define a variable that
> +	% occurs in the access path to OldLval (and which therefore indirectly
> +	% modifies the value that OldLval refers to), because our caller will
> +	% call us only with OldLvals (and NewLvals for that matter) that have
> +	% no lvals in their access path.
> +	%
> +	% This predicate takes a conservative view of what may define OldLval.
> +	% For some instruction types, we simply give up. Since these
> +	% instruction types are relatively rare, the effect on the performance
> +	% of the generated code should be negligible.
> +
> +:- pred substitute_lval_in_instr_until_defn(lval::in, lval::in,
> +	list(instruction)::in, list(instruction)::out, int::in, int::out)
> +	is det.
> +
> +substitute_lval_in_instr_until_defn(_, _, [], [], N, N).
> +substitute_lval_in_instr_until_defn(OldLval, NewLval,
> +		[Instr0 | Instrs0], [Instr | Instrs], N0, N) :-
> +	Instr0 = Uinstr0 - _,
> +	(
> +		Uinstr0 = comment(_),
> +		Instr = Instr0,
> +		substitute_lval_in_instr_until_defn(OldLval, NewLval,
> +			Instrs0, Instrs, N0, N)
> +	;
> +		Uinstr0 = livevals(_),
> +		Instr = Instr0,
> +		Instrs = Instrs0,
> +		N = N0

Is that one of the places where you're making a conservative
approximation?

It would help quite a bit if you put a comment in front of each
such place.

Otherwise, that looks fine.

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



More information about the developers mailing list