Compiler heuristics

[Igor Stasenko]

On 26/12/2007, bryce at kampjes.demon.co.uk <bryce at kampjes.demon.co.uk> wrote:

> What you're talking about sounds very much like specialisation which
> was done by Craig Chambers in a Self VM before they started using
> dynamic type feedback.
>
> The harder part in your case is figuring out what = should mean.
> There are 126 implementers of = in my image. That said, you could
> look in the PICs to see what classes have been used previously then
> just deal with those cases allowing for an un-optimised fall-back
> position. If we could guarantee that = was side effect free then
> specialisation would be a lot easier.
>

Suppose, code provided is a code generated by compiler (to deal with oops)
As for smallintegers, you can check a tag bit only once and then skip
check in later code, because you already know that it's a
smallinteger.
It's also, can be possible for objects (if we know what = doing).
In general, we can reduce the problem to proving that, if we got
result from #= message and receiver is not changed, then we should
expect to have similar result when we call #= later.
So, we are free to replace send of #= by result of previous invocation.


-- 
Best regards,
Igor Stasenko AKA sig.