Re: Adding Identities to Peval

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Noah Lavine <address@hidden> writes:
>>
>>> Hello,
>>>
>>> I've been working on a patch to add a new sort of optimization to
>>> peval, and I think it's almost ready. It's based on some of the ideas
>>> in "Environment Analysis of Higher-Order Languages".
>>>
>>> The goal is to recognize when two quantities are equal even when we
>>> don't know what they are. My working example has been this expression:
>>>
>>> (let* ((x (random))
>>>        (y x))
>>>   (eq? x y))
>>>
>>> The patch attached to this message lets peval optimize that to
>>>
>>> (begin (random) #t)
>>
>> I have a hard time imagining this optimization to be useful for any code
>> occuring in practice.  Can you suggest an example that would make more
>> sense than demonstrating that the optimization works?  Is this supposed
>> to help with automatically generated code like macros?
>
> Actually, I've been just racking my brain over how to write this better:
>
>             {
>             // We end only one slur unless several ones have been
>             // caused by the same event, like with double slurs.
>               if (!ended || scm_is_eq (starter,
>                                      slurs_[j]->get_property ("cause")))
>               {
>                 ended = true;
>                 starter = slurs_[j]->get_property ("cause");
>                 end_slurs_.push_back (slurs_[j]);
>                 slurs_.erase (slurs_.begin () + j);
>               }
>             }
>
> The problem is that if you enter the "if" through the second alternative
> condition, you can just jump past the first two assignments (because
> they assign values that are already known to be in the respective
> variables).  I've not found a good way to handoptimize this short of
> using goto or abusing do ... while;

So if you want to make this into some sort of feedback: in this
particular case, the equality of some variables is not known because one
has been assigned to another, but because one has arrived from a code
path where the equality has been established by a test.

-- 
David Kastrup