Inliner strangeness

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Inliner strangeness

Andreas.Raab
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
Reply | Threaded
Open this post in threaded view
|

Re: Inliner strangeness

johnmci
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 <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

Reply | Threaded
Open this post in threaded view
|

Re: Inliner strangeness

Bert Freudenberg-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Inliner strangeness

johnmci
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 <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===