From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel 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 Message-ID: References: <8738wsonml.fsf@tines.lan> <87621ogukm.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b338f1fc0f1e504d616bbe2 X-Trace: ger.gmane.org 1361293048 3301 80.91.229.3 (19 Feb 2013 16:57:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Feb 2013 16:57:28 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 19 17:57:48 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U7qVo-0005Yz-1a for guile-devel@m.gmane.org; Tue, 19 Feb 2013 17:57:48 +0100 Original-Received: from localhost ([::1]:34374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7qVU-0003PQ-0U for guile-devel@m.gmane.org; Tue, 19 Feb 2013 11:57:28 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7qVP-0003Oy-Nk for guile-devel@gnu.org; Tue, 19 Feb 2013 11:57:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7qVH-00013b-IE for guile-devel@gnu.org; Tue, 19 Feb 2013 11:57:23 -0500 Original-Received: from mail-pa0-f42.google.com ([209.85.220.42]:65365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7qVH-00013Q-8Y for guile-devel@gnu.org; Tue, 19 Feb 2013 11:57:15 -0500 Original-Received: by mail-pa0-f42.google.com with SMTP id kq12so3536274pab.15 for ; Tue, 19 Feb 2013 08:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yJDGrpdDrSw5cXfg9ldkaQJ41sv9ZHqiP1jCpzOpPR0=; b=xQwQMJfx82kv7bAaKtjR9oQj07ZywQAHNuM/w5yGaBiRX59ekMAFl01EIs6iet/hjf IfwuOQ+7gjB+LoMGjpGl6+eAkRA7bSl7v6HyjGkS6NKifCnoPVjE4D9WgUvT0RAzm9AD P5VGUhNAyKl/P/4VMCp97hI70woif7QPKXxgbWvzpx2gO4rrgnD40oBkBI5F1mGyJPoz q4LTdwnOBvCV1Ozw7Epf75WUaVtdMED5MKg7+rKkXowBj+NJaR43xiljn1jm01BrmDra ASW91cUdaQ50Z/aUp9Mu9mTvB9eTF9cCfu5FUSfvvv/x4oPZ3ZuR+nEKsB97SQpEaWK5 BV1w== X-Received: by 10.68.237.165 with SMTP id vd5mr41998105pbc.52.1361293034451; Tue, 19 Feb 2013 08:57:14 -0800 (PST) Original-Received: by 10.68.157.42 with HTTP; Tue, 19 Feb 2013 08:57:14 -0800 (PST) In-Reply-To: <87621ogukm.fsf@tines.lan> X-Google-Sender-Auth: vBGYD44Y9c-2iNon3-y9MHbIpIU X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.42 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15783 Archived-At: --047d7b338f1fc0f1e504d616bbe2 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Tue, Feb 19, 2013 at 11:03 AM, Mark H Weaver wrote: > Hi Noah, > > Noah Lavine 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 --047d7b338f1fc0f1e504d616bbe2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

On Tue, Feb 19, 2013 at 11:03 AM, Mark H Weaver <mhw@netris.org= > wrote:
Hi Noah,

Noah Lavine <noah.b.lavine@gm= ail.com> 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<= br> > working. I plan to implement un-boxing in CPS.

You still seem to be proceeding from the assumption that the conversi= on
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. =A0It 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. =A0We already have an
increasingly sophisticated set of optimization passes implemented in
tree-il. =A0Those 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 ha= ve a compiler in which some optimizations are done in Tree-IL and some in C= PS, and once we have that, we can play with which optimizations happen wher= e.

So for now, yes, you are completely correct= . However, you might like my other reason better: the Tree-IL->CPS compi= ler 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 t= hem. Once the Tree-IL->CPS compiler can handle interesting cases, then w= e can start optimizing the uninteresting ones away.

Best,
Noah

<= /div>
--047d7b338f1fc0f1e504d616bbe2--