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

[Fergus Henderson]

On 17-Aug-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 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.

So the situation you want to avoid is is

	r1 = <value of input arg>;
	Word input_arg = r1;
	...
	SUCCESS_INDICATOR = r1;
	
> 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 :-).

I think it would be a lot simpler if we could adopt the same treatment
of the globals for all of the passes, rather than different treatments
for different passes.

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

But that could give the wrong result whenever a procedure with both a
module info and an io__state calls a procedure with just an io__state,
and the called procedure looks up an option.

> It is always a bad idea to have two copies of a data structure:
> you never know which one is authoritative.

I agree with the general principle.  However, in this case we can solve
the problem by ensuring that they are always both authoritative.
I think this is going to be a much simpler solution than the alternatives.

> > 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 [...]

OK, great -- I agree this is a much better fix.

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