[m-dev.] for review: a replacement of code_exprn.m

[Zoltan Somogyi]

On 17-Aug-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 06-Aug-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > compiler/pragma_c_gen.m:
> > 	When using var_locn, ensure that none of the input arguments is
> > 	assigned to r1, in order to avoid forcing the C compiler to generate
> > 	code to shuffle it out of the way.
> 
> I don't understand that.
> Why would the C compiler generate code to shuffle r1?

Thanks for doing the review.

[I reach back to a subtle point I last thought about in April.
Delayed reviews are a PITA.]

I have replaced the log message with

	When using var_locn, ensure that none of the input arguments of a 
	model_semi pragma_c_code is assigned to r1. If we did, and the last
	reference to the value of that argument was after an assignment to
	SUCCESS_INDICATOR, the C compiler would be forced to generate code 
	to shuffle the value of the argument out of the way.

I have also modified the relevant comment in the source code in same fashion.

> > compiler/mercury_compile.m:
> > compiler/code_gen.m:
> > 	Turn off tracing in any predicate that originates in a builtin module
> > 	for backend_by_preds and backend_by_phases respectively.
> >
> > 	Look up options in the globals structure in the module_info, not in the
> > 	globals structure in the I/O state, since this is where we turn off
> > 	tracing. (We should later make sure that other parts of the compiler
> > 	are also consistent on this issue.)
> 
> I think it would be much better to just set the globals in both the io__state
> and the module_info.  Trying to ensure that other parts of the
> compiler only access the globals via the module_info rather than via
> the io__state is not going to work, because there are lots of places
> in the compiler that only get passed the io__state, not the module_info.

Actually, this is true but not very relevant. Most of the passes in the front
end get IO states but not module infos, partially because many fields of the
module info have not been defined yet. However, very few of the passes in
the back end have IO states, and all the relevant ones have module infos.
My change only involves the back end. (The middle passes are, well ...
in the middle on this issue as well :-).

> Passing down the module_info to all of those places would be a nightmare...

... but is not required. The consistency I had in mind is using the globals
in the module info if you have a module info, and using the globals directly
otherwise. I don't think we should use the globals in the IO state any more
than necessary, and I don't think it is necessary once the options have been
processed. It is always a bad idea to have two copies of a data structure:
you never know which one is authoritative.

Another possibility is that mercury_compile always hands the globals
explicitly to whatever modules it invokes, with the globals being taken
out of the module info and never stored in the IO state either after the
options have been processed. Then each pass just puts the globals into
its own structure (det_info, simplify_info etc) so that it does not have
to pass it around separately. Come to think of it, I think this is probably
the best approach in the long term.

> > +++ call_gen.m	2000/08/03 08:53:28
> > @@ -97,19 +98,14 @@
> >  	code_info__get_instmap(InstMap),
> >  	{ goal_info_get_instmap_delta(GoalInfo, InstMapDelta) },
> >  	{ instmap__apply_instmap_delta(InstMap, InstMapDelta, ReturnInstMap) },
> > -	{ call_gen__output_arg_locs(ArgsInfos, OutputArgLocs) },
> > -		% We must update the code generator state to reflect
> > -		% the situation after the call before building
> > -		% the return liveness info. No later code in this
> > -		% predicate depends on the old state.
> > -	call_gen__rebuild_registers(ArgsInfos),
> > -	code_info__generate_return_live_lvalues(OutputArgLocs, ReturnInstMap,
> > -		ReturnLiveLvalues),
> >  
> > +		% Update the code generator state to reflect the situation
> > +		% after the call.
> > +	call_gen__handle_return(ArgsInfos, ReturnInstMap, ReturnLiveLvalues),
> > +
> >  		% Make the call.
> >  	code_info__get_module_info(ModuleInfo),
> 	...
> 
> With this change, the code & comments are somewhat mystifying: why
> does it "update the code generator state to reflect the sitatuation
> after the call" *before* (generating code to) make the call?
> 
> Hence I prefer the old comment.

I agree that the comment clashes with the following code. However, a
simpler fix is to simply switch those two code blocks, so that the call to
call_gen__handle_return is after the code that generates the call instruction.
This is possible because the code that generates the call instruction depends
on the code generator only to the extent of allocating a label number.
This gets rid a comment that is unnecessarily confusing; in its new position
the part about "No later code in this predicate depends on the old state"
does not need stating, since there is almost no "later code".

I have done this fix in both copies of this code, ordinary and generic calls
(which construct different call instructions).

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