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 _______________________________________________ Exupery mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
