Compiler heuristics

[bryce at kampjes.demon.co.uk]

Igor Stasenko writes:
 > It's a theoretical question, rather than practical concerning Exupery,
 > but i'd like to know, what you know/thinking about special compiler
 > heuristics concerning simplifying expressions, when do inlining.
 > 
 > The problem, in basic can be demonstrated by following example.
 > 
 > Suppose you having a code:
 > 
 > mainMethod
 >    object = 0 ifTrue: [ object method1 ] ifFalse: [ object method2]
 > 
 > and now method bodies:
 > 
 > method1
 >    object = 0 ifTrue: [ do something] ifFalse: [ do something else ]
 > 
 > method2
 >    object ~= 0 ifTrue: [ do something] ifFalse: [ do something else ]
 > 
 > Now, the question is, when you inlining method1/2 into mainMethod
 > you can see, that tests in inlined methods become redundant.
 > If we inline both methods, code will look like:
 > 
 > mainMethod
 >    object = 0 ifTrue: [
 >        object = 0 ifTrue: [ do something]
 >        ifFalse: [ do something else ]  ]
 >    ifFalse: [
 >        object ~= 0 ifTrue: [ do something]
 >        ifFalse: [ do something else ] ]
 > 
 > Is there any techniques, which can help in removing such redundancy,
 > when analyzing code by compiler?

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.

Bryce