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

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

[Mark H Weaver]

Hi Noah,

"Noah Lavine" <noah.b.lavine@gmail.com> writes:
> commit 0d0808ae3f7390ffb250b9deb6706ad4158cce0e
> Author: Noah Lavine <noah.b.lavine@gmail.com>
> Date:   Mon Feb 18 14:10:58 2013 -0500
>
>     Make Lambda Arguments Mutable
>     
>     * module/language/cps.scm: let variable objects come with an
>       initialization value.
>     * module/language/tree-il/compile-cps.scm: put all lambda arguments in
>       variable boxes, so they are mutable.

Lambda arguments (and all other lexical variables) should only be put
into boxes if they are 'set!' somewhere within their lexical scope.
This can always be determined at compile time.  It is crucial that we
minimize the number of mutable variables, since they inhibit most
optimizations.

The required analysis is already implemented in tree-il/analyze.scm.

     Regards,
       Mark

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

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

Hello,

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. The real reason not to do it yet is that the
tree-il-CPS compiler can't compile any examples that would actually need
boxes. (But it will be able to soon!)

Noah


On Tue, Feb 19, 2013 at 12:53 AM, Mark H Weaver <mhw@netris.org> wrote:

> Hi Noah,
>
> "Noah Lavine" <noah.b.lavine@gmail.com> writes:
> > commit 0d0808ae3f7390ffb250b9deb6706ad4158cce0e
> > Author: Noah Lavine <noah.b.lavine@gmail.com>
> > Date:   Mon Feb 18 14:10:58 2013 -0500
> >
> >     Make Lambda Arguments Mutable
> >
> >     * module/language/cps.scm: let variable objects come with an
> >       initialization value.
> >     * module/language/tree-il/compile-cps.scm: put all lambda arguments
> in
> >       variable boxes, so they are mutable.
>
> Lambda arguments (and all other lexical variables) should only be put
> into boxes if they are 'set!' somewhere within their lexical scope.
> This can always be determined at compile time.  It is crucial that we
> minimize the number of mutable variables, since they inhibit most
> optimizations.
>
> The required analysis is already implemented in tree-il/analyze.scm.
>
>      Regards,
>        Mark
>

[-- Attachment #2: Type: text/html, Size: 1939 bytes --]

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

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

Oh, and thanks a lot for reviewing the CPS stuff! I really appreciate it,
and I think it will make the end result a lot better than whatever I could
do on my own.

Noah


On Tue, Feb 19, 2013 at 9:28 AM, Noah Lavine <noah.b.lavine@gmail.com>wrote:

> Hello,
>
> 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. The real reason not to do it yet is that the
> tree-il-CPS compiler can't compile any examples that would actually need
> boxes. (But it will be able to soon!)
>
> Noah
>
>
> On Tue, Feb 19, 2013 at 12:53 AM, Mark H Weaver <mhw@netris.org> wrote:
>
>> Hi Noah,
>>
>> "Noah Lavine" <noah.b.lavine@gmail.com> writes:
>> > commit 0d0808ae3f7390ffb250b9deb6706ad4158cce0e
>> > Author: Noah Lavine <noah.b.lavine@gmail.com>
>> > Date:   Mon Feb 18 14:10:58 2013 -0500
>> >
>> >     Make Lambda Arguments Mutable
>> >
>> >     * module/language/cps.scm: let variable objects come with an
>> >       initialization value.
>> >     * module/language/tree-il/compile-cps.scm: put all lambda arguments
>> in
>> >       variable boxes, so they are mutable.
>>
>> Lambda arguments (and all other lexical variables) should only be put
>> into boxes if they are 'set!' somewhere within their lexical scope.
>> This can always be determined at compile time.  It is crucial that we
>> minimize the number of mutable variables, since they inhibit most
>> optimizations.
>>
>> The required analysis is already implemented in tree-il/analyze.scm.
>>
>>      Regards,
>>        Mark
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2639 bytes --]

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

[Mark H Weaver]

Hi Noah,

Noah Lavine <noah.b.lavine@gmail.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
> 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?

    Regards,
      Mark

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

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Hello,

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

> Hi Noah,
>
> Noah Lavine <noah.b.lavine@gmail.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
> > 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

[-- Attachment #2: Type: text/html, Size: 2866 bytes --]