[kaffe] Re: inlining sysdepCallMethod for m68k-linux

[Dalibor Topic]

Hi Nathan,

Nathan Carl Summers wrote:
> On Thu, 22 Apr 2004, Kiyo Inaba wrote:
> 
> 
>>Riccardo wrotes:
>>But, the real concern for me is which version of environment we can
>>support. In general, if we make more CPU/OS (with different versions)
>>supported, the usefulness of kaffe becomes bigger, but of course we
>>need not to be so strong-headed of this issue. This specific case is
>>one of these tradeoffs, if inlining with alloca works with newer
>>versions of gcc.
> 
> 
> Of course, you can always use some sort of #ifdef to make it work with the
> older compilier while taking advantage of the inlining with the newer
> compiler.
> 
> On the other hand, changing a macro with alloca in it to an inline
> function is probably not what you want.  It seems to me like the whether
> the alloca'd memory would be deallocated when the inline function returns
> is a quite ambigous case, and almost certainly buggy when the optimization
> flags aren't set to enable inlining.

When I look at the sparc warnings from 
http://multix.dyndns.org/Sites/kaffe-devel/machines/legolas/buildlog-sunos-22-Apr.Z 
I see that it's been compiled with gcc3, and Riccardo says it was gcc 
3.3. The funny thing is that shouldn't have problems inlining code using 
alloca on i386-linux, since gcc 3.2.1 seems to do that without warnings 
on my linux box.

So I assume that the failure to inline code using alloca is not just gcc 
version dependant, but also depends on the cpu architecture.

The trouble is that the code in config/sparc/sysdepCallMethod.h uses 
dynamic arrays, too, to deal with the 
'too-long-for-passing-in-registers' number of arguments. The sparc 
sysdepCallMethod code looks very complicated, the file needs to be 
included twice and what not. So turning that one into a macro could be a 
lot of work for a volunteer.

The simple way to deal with the inlining warnings, by sacrificing some 
performance, would be to turn sysdepCallMethod into an exported 
function, that's compiled in its own file. I have no idea how high the 
performance penalty would be, but if that fixes the problems with 
buggy/insufficiently-advanced optimizers, then I think it's worth it.

Judging by http://www.kaffe.org/pipermail/kaffe/2000-March/037887.html 
sysdepCallMethod does not have to be inlined, or a macro. It seems to 
have been done purely for speed reasons. So it would be interesting if 
turning sysdepCallMethod into a 'normal' function has any beneficial 
effect on m68k-linux, for example, or on other platforms where this 
warning occurs.

cheers,
dalibor topic