Inliner strangeness
Bert Freudenberg
bert at impara.de
Fri Jun 9 08:08:13 UTC 2006
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
More information about the Vm-dev
mailing list