[kaffe] Re: inlining sysdepCallMethod for m68k-linux
Dalibor Topic
robilad at kaffe.org
Mon Apr 26 07:10:43 PDT 2004
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
More information about the kaffe
mailing list