Re: CPS Update

[Noah Lavine]

Hello,

On Sat, Feb 16, 2013 at 2:14 PM, Mark H Weaver <address@hidden> wrote:

Noah Lavine <address@hidden> writes:
> Oh, you're right. I was thinking about that because I don't run the
> Tree-IL optimizers when I test it, so I don't get any Tree-IL
> primitives.

I think you should be running the existing tree-il passes before you
convert to CPS.  As I pointed out earlier, many optimizers will not be
able to work well after conversion to CPS, fundamentally because CPS
loses information about where order of evaluation is unspecified.

Furthermore, some of the existing passes make important simplifications
to the resulting tree-il.  For example, the code in fix-letrec.scm
eliminates all <letrec> nodes, so that's one less thing for you to have
to implement.  Primitives.scm marks primitives explicitly using
<primcall> tree-il nodes, so that later code doesn't have to make thorny
assumptions about what variables should be considered primitives.

Interesting points. I think you're right that Tree-IL should be optimized first. For the specific issue of order of evaluation, I'm hoping to add something (either a special function or a special node type) to CPS to represent continuations that can be evaluated in any order. It seems like evaluation order is a decision that should be made in either the code generator or the register allocator, and those operate on CPS. I also dislike losing information.

 

> I think I read that loading GOOPS turns things like '+ into generic
> operations - that might be a case where this matters a lot.

No, because GOOPS has a special mechanism for cases like '+': they are
called "primitive generics".  When numerical operations are unable to
handle the argument types provided, they calls 'scm_wta_dispatch_*'.
Therefore, adding new methods to numerical operations does not involve
changing their bindings.  This is good because it means that you can
extend numerical operations without slowing them down at all for
built-in numbers.

I see. That's very cool.

 

> I have thought a bit about how to fix this. The module system already
> allows us to be notified whenever a variable changes, so it would be
> easy to watch all of the variables in (guile) and recompile procedures
> when they change. I might take a look at this soon.

This would be nice too, of course, but I warn you that it's a can of
worms.  In the general case, it involves on-stack replacement, because
you might need to recompile a procedure that's currently in the middle
of being run, and thus currently has activation records on the stack(s).

You mean if a function modifies another function that called it. Yes, that seems complicated. It's not very important to me to fix it in general, because I don't know of a case where it's useful. I think fixing it without the on-stack replacement would be a reasonable compromise.

 

Thanks for you work on this, Noah!

Thank you!

Noah