Inliner strangeness

> 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

> 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

> 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
>
>