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
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
