[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