guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Guile-commits] GNU Guile branch, wip-rtl-cps, updated. v2.1.0-180-g


From: Noah Lavine
Subject: Re: [Guile-commits] GNU Guile branch, wip-rtl-cps, updated. v2.1.0-180-g0d0808a
Date: Tue, 19 Feb 2013 11:57:14 -0500

Hello,

On Tue, Feb 19, 2013 at 11:03 AM, Mark H Weaver <address@hidden> wrote:
Hi Noah,

Noah Lavine <address@hidden> writes:
> Yes, I completely agree with this. I didn't do that immediately
> because I'm trying to get the infrastructure for the general case
> working. I plan to implement un-boxing in CPS.

You still seem to be proceeding from the assumption that the conversion
to CPS will happen early, and that all optimizations will happen in CPS.
I continue to think that this is a bad idea, because of the order of
evaluation issue.

I realize that you intend to extend CPS with some way to express
unspecified evaluation order, but I'm not sure that is a good idea.
The fact that CPS fully specifies evaluation order is not merely an
undesirable flaw to be remedied.  It is fundamental to the nature of
CPS form, and an important part of what makes CPS desireable as an IR.
I fear that in trying to get the best of both worlds, you will instead
end up with the worst of both worlds.

I suspect that the way to get the best of both worlds is to do several
optimizations *before* conversion to CPS.  We already have an
increasingly sophisticated set of optimization passes implemented in
tree-il.  Those early passes already analyze whether or not lexicals
need to be mutable or not, and make several optimizations that depend on
having this information.

Do you intend to rewrite all of those passes for CPS?

That's a fair point. I do think that some of those optimizations would work better in CPS, but even if that's true, I don't want to port them all at once. I agree that the goal should be to have a compiler in which some optimizations are done in Tree-IL and some in CPS, and once we have that, we can play with which optimizations happen where.

So for now, yes, you are completely correct. However, you might like my other reason better: the Tree-IL->CPS compiler can't compile any cases that really need mutable variable slots, so I had to test mutable variables with examples that really don't need them. Once the Tree-IL->CPS compiler can handle interesting cases, then we can start optimizing the uninteresting ones away.

Best,
Noah


reply via email to

[Prev in Thread] Current Thread [Next in Thread]