[squeak-dev] Squeak4.2-10892-beta image

Eliot Miranda eliot.miranda at gmail.com
Thu Jan 13 17:25:59 UTC 2011


2011/1/13 Levente Uzonyi <leves at elte.hu>

> On Thu, 13 Jan 2011, Nicolas Cellier wrote:
>
>  Follow up on unused temps :
>>
>> Wanna play with temps ? Try this :
>>
>> testUnusedVariable
>>        self
>>                compiling: 'griffle | goo | ^nil'
>>                shouldRaise: UnusedVariable;
>>                compiling: 'griffle | | ^[ | goo | ]'
>>                shouldRaise: UnusedVariable;
>>                compiling: 'griffle | | [ | goo | goo := nil. goo]
>> yourself. ^[ | goo | ]'
>>                shouldRaise: UnusedVariable;
>>                compiling: 'griffle | | [ | goo | ] yourself. ^[ | goo |
>> goo := nil. goo]'
>>                shouldRaise: UnusedVariable
>>
>> What happens is that Parser.scopeTable has a single entry for 'goo'.
>> Consequently, the last registered goo wins.
>> In the 3rd case, the last goo is unused, so hasRef = false, so
>> UnusedVariable is raised.
>> In the 4th case, the last goo nowHasRef, and we don't get any
>> UnusedVariable.
>>
>> Until we get a scopeTable mapping each temp of each block, we gonna
>> live in trouble.
>>
>
> Right. I'd probably create a separate class for the Encoder's scopeTable,
> because it's accessed in various ways from several places and it's hard to
> see what change will have side effects in the current code. But I'm a total
> newbie in this area, so I may be wrong.
>

That's a good idea.  One goal for anyone who tries to do anything in this
area is to collapse optimized temps.  e.g. in the following

    1 to: self size do: [:i| ...].
     1 to: self size do: [:j| ...]

or
    1 to: self size do: [:i| ...].
    1 to: self size do: [:i| ...].

the current scope table makes it really hard to use the same temp slot for
either i and j or both i's.  Since these temps are out of scope after their
blocks their temps should be reused.  But the compiler keeps the
in-scope/out-of-scope info in the temp nodes themselves, so this can't be
done.

Collapsing temps of different names is probably not feasible because there's
no way to add teh necessary scope information to the debugger temp names
string and so no way of saying "temp #T is called 'i' from bytecode M to
bytecode N but is called 'j' from bytecode O to bytecode P".  But collapsing
temps with the same name is straight-forward and judging by all the code
I've eyeballed in working on the closure compiler I'd say it was worth it,
not least because certain large methods would limbo under the 56 slot max
temp limit which wouldn't otherwise.  remember that GeniePlugin method that
couldn't be compiled until it was refactored.

2¢
Eliot

Levente
>
>
>
>> Nicolas
>>
>> 2011/1/12 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>
>>> 2011/1/12 Levente Uzonyi <leves at elte.hu>:
>>>
>>>> On Wed, 12 Jan 2011, Chris Muller wrote:
>>>>
>>>>  I've just posted a new beta image at:
>>>>>
>>>>>  ftp://ftp.squeak.org/4.2/
>>>>>
>>>>> This one does not have wrecked PackageInfo's, and has most (but not
>>>>> all) of the aesthetic changes for 4.2.
>>>>>
>>>>> The test suite is looking better:
>>>>>
>>>>> 'CompilerExceptionsTest>>#testUnusedVariable
>>>>>
>>>>
>>>> This one is new, I'd be happy if someone could have a look at it.
>>>>
>>>>
>>> This is due to latest improvements from Eliot.
>>> Now the BlockNode have their own tempsMark (set by
>>> Parser>>#temporaryBlockVariablesFor:).
>>> The Parser only records top level tempsMark in Parser>>#temporaries.
>>>
>>> If you look at the code in Parser>>#removeUnusedTemps, you see some
>>> defensive programming
>>>        ((tempsMark between: 1 and: str size)
>>>                and: [(str at: tempsMark) = $|]) ifFalse: [^ self].
>>>
>>> But hey, the top level does not have any tempsMark, so the method
>>> prematurely returns without checking for some unused in the blocks.
>>> self
>>>        justTriedCompiling: 'griffle | | ^[ | goo | ]'
>>>        andItCorrectlyRaised: UnusedVariable.
>>>
>>> Shall we remove the tempsMark protection ?
>>>
>>> Nicolas
>>>
>>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110113/3d96681e/attachment.htm


More information about the Squeak-dev mailing list