chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] Handling multiple args in types.db


From: megane
Subject: Re: [Chicken-hackers] Handling multiple args in types.db
Date: Sat, 27 Apr 2019 11:12:09 +0300
User-agent: mu4e 1.0; emacs 25.1.1

Peter Bex <address@hidden> writes:

> On Sat, Apr 27, 2019 at 09:35:21AM +0300, megane wrote:
>> Peter Bex <address@hidden> writes:
>> > Ah, so this effectively means some of the rewrites are useless since the
>> > specializations make them inapplicable.  We should consider what to do
>> > with that.  I have no clue what would happen if we change the order in
>> > which they run, so maybe just remove rewrite 19 and replace it with your
>> > suggestion?
>>
>> In this case I would just move rewrite 19 to happen before scrutiny.
>
> I don't think we can selectively move particular rewrites before scrutiny,
> that's what I was getting at; scrutiny is just one big operation that
> runs once, and optimizations happen in a loop.

I see, I see.

>
>> In general, some optimizations like rewrite 19 help the scrutinizer. The
>> scrutinizer makes transformations that might enable some optimizations,
>> which might help the scrutinizer, ... i.e. "cascading optimizations".
>
> Yeah, it would be great to make use of that.
>
>> The optimizer seems to do this kind of looping. The scrutinizer just
>> isn't part of that (and probably can't be as the optimizer works with
>> CPS IIUC).
>
> That's what I mean.  So I think (for now at least?) we're "stuck" with
> doing it like you suggested, but then the rewrite is unnecessary (for the
> most part?).

I think the declarative way of doing the thing rewrite 19 is doing is
better than manually doing it in types.db like I suggested.

I think this rewrite 19 thing could be solved in the scrutinizer. This
would in preparation for that "cascading optimization" feature.

In scrutinizer, just at the beginning of 'walk' just try different kind
of optimizations. Like rewrite 19 and the constant folding thing that
was added recently (which is done in pretty icky place currently). Like
this:

  (try-optimizations node)
  .. continue with normal walk ..

The optimizations done here would be "scrutinizer-aware" in that they
don't make scrutiny harder.

Starting this way would be pretty easy and shouldn't add much new hair
(famous last words...)

Thoughts?

>
> Cheers,
> Peter



reply via email to

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