Inliner strangeness
John M McIntosh
johnmci at smalltalkconsulting.com
Fri Jun 9 17:15:44 UTC 2006
Actually I think I've seen
self touch: foo
which is removed by the CCodeGenerator, mind I've not check this to
see when it's removed in relationship to the inliner logic.
On 9-Jun-06, at 1:08 AM, Bert Freudenberg wrote:
> The pattern to avoid this inlining "strangeness" would be
>
> Interpreter>>getFoo
> ^self cCode: 'foo' inSmalltalk: [foo]
>
> so the inliner sees the second access.
>
> - Bert -
>
> Am 09.06.2006 um 00:47 schrieb John M McIntosh:
>
>> This was done on purpose years ago to inline all the variables in
>> the GC logic.
>>
>> If you have one accessor and one usage of the variable in another
>> routine and say not to inline the accessor,
>> then the inliner won't fold the global into a local variable.
>> Your code example follows the rules nicely because you've only
>> one usage of the foo variable we can see and why make it a global...
>>
>>
>> On 8-Jun-06, at 1:53 PM, Andreas Raab wrote:
>>
>>> Hi -
>>>
>>> I don't know if this behavior has been in the CCode inliner
>>> before but I just noticed that the inliner will forcefully
>>> convert iVars to temps if that iVar is only explicitly referred
>>> to in a single method. Like, for example here:
>>>
>>> Interpreter>>getFoo
>>> ^self cCode: 'foo'
>>>
>>> Interpreter>>setFoo: fooValue
>>> foo := fooValue.
>>>
>>> The above will cause the inliner to remove foo from the regular
>>> interpreter variables (even if declared via #declareCVarsIn:) and
>>> move it into #setFoo:. With the foreseeable result of creating
>>> total and utter nonsense in the resulting C code.
>>>
>>> Has anyone seen that before?
>>>
>>> Cheers,
>>> - Andreas
>
>
--
========================================================================
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===
More information about the Vm-dev
mailing list