David Kastrup <d...@gnu.org> writes:
> David Kastrup <d...@gnu.org> writes:
>
>> Noah Lavine <noah.b.lav...@gmail.com> 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
