Compiler heuristics
bryce at kampjes.demon.co.uk
bryce at kampjes.demon.co.uk
Wed Dec 26 14:23:08 UTC 2007
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
More information about the Exupery
mailing list