inlining methods in slang

Tim Rowledge tim at
Tue May 3 19:46:16 UTC 2005

Martin Kuball <MartinKuball at> wrote:

> Am Monday 02 May 2005 09:48 schrieb John M McIntosh:
> > You should look at
> > CCodeGenerator>>collectInlineList
> >
> > to understand why your code does not get inlined.
> >
> Well, the offending line is
>    self var: #output type: 'unsigned char*'.
> The inlined code can do well without it. But the code generated for 
> the method does not compile without it. So my question is still: why 
> do inlined methods get their own c method definitions? I think I 
> could live without them.

It's all down to how clever (or stupid) the inlining code is. Since the
inlining is done purely on a textual basis it isn't smart enough to do semantic
analysis or C block analysis etc; so when you have any C declaration in a
translated method it gets marked as non-inlinable. Note the line in
#collectInlineList that goes
	hasCCode := m declarations size > 0.
and consider it along with TMethod>recordDeclarations. If you (or anyone) can
think of a way to handle C declarations in the inlining process, don't hesitate
to suggest code.

An alternative that hasn't been tried yet is to stop doing the inlining
ourselves and instead mark generated functions for the C compiler to inline. So
far as I can tell all current C compilers accept an inline pragma and I suspect
could do a much better job. Someone with some time and a wish to help might
like to investigate. Generate the VM code with our inlining turned off but add
some code to stick the C inline pragma in the function declarations when we
have a self inline: true.  Run sensible benchmark suites. Gain fame. 

Tim Rowledge, tim at,
I am still waiting for the advent of the computer science groupie.

More information about the Squeak-dev mailing list