[m-dev.] for review: MLDS code generator design

[Zoltan Somogyi]

> > I think you also need to deal with conditions that are det. Probably
> > due to the extra sequencing required for ites, they are not transformed
> > into conjunctions.
> 
> That's not correct -- if-then-elses with conditions that cannot fail do
> get transformed into conjunctions.  See simplify.m line 882.

I know that. I also know that a year or two ago I had to add code to the
code generator to handle this case. I don't know it slipped past simplify.

> > I don't think the XXX is warranted at all. At the point just before <Then>,
> > you can clobber (set to NULL) all variables only needed in the Else path,
> > and vice versa.
> 
> Sure, but doing that is a bit tricky.  Not very tricky, I agree,
> but nevertheless this is something I will leave out of version 0.1
> (implementing switches, negations, etc. is more important than
> getting perfect GC...) so for now I'll leave the XXX there.

In that case, you should also add a similar comment to disjunctions; when you
fail out of a disjunct, you want to clobber all variables that were needed
only in that disjunct.

> The reason for using nested functions is mainly to keep the transformation
> simple, not for efficiency.

My point was that generating code that avoids nested functions will probably
be simpler than (a) writing code that uses nested functions, plus (b)
optimizing them away. However, your comment

> In general compiling to nested functions gives the target compiler more
> chance of optimizing things.  Compilers typically do liveness analysis
> and allocate local variables with disjoint lifetimes into the same stack
> slot, and if the target compiler supports nested functions then it may
> well be able to do a good job of that even in the presence of nested
> functions -- particularly if it inlines the calls to the nested functions.
> On the other hand, compilers generally _don't_ do a good job of optimizing
> structs, particularly not when the struct's address is taken.

is a sufficient reason for preferring your approach.

> Furthermore, separating out way we implemented nested functions into
> a separate post-pass is a good idea because will probably we need to
> use a different post-pass when generating Java than the one we use when
> generating C.  Java doesn't have pointers; instead of passing a pointer
> to a struct and a function pointer, we'll want to pass an object containing
> a virtual function.

This is not a sufficient reason, because it ought to be simple to design
a single MLDS data structure to handle both of these. This difference ought
to manifest itself only when you convert from MLDS to C or Java.

> These scheme I've outlined only does two things with continuations:
> it passes them as arguments, and it calls them.  They are
> never returned and never stored inside heap objects or in global variables.
> These conditions are sufficient to ensure that this scheme won't suffer
> from that problem.
> 
> (In the case where the Mercury source code contains higher-order code,
> the Mercury closures will be implemented by creating terms on the heap,
> not by using nested functions.)

Include these points in the documentation.

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