Re: Patch: gcj optimizations

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Tom Tromey wrote:

>This patch changes gcj so that it recognizes certain library calls and
>instead changes them into inline code.
>
Cool! This is one of those things I've wanted to do for ages, but never 
got around to ;-)

I would like to see a more "generic" framework for doing this. That is, 
instead of having identifiers in JTI_GLOBAL_TREES, have a separate 
table, perhaps in a new file (builtins.{c,h} or inlines.{c,h}?) of known 
inlineable functions. Rather than an if-then-else in the code to 
determine if a method is a known-inlineable, have a function to iterate 
through this table and see if the called method is in it. It would also 
be nice to put the code that generates trees for the inlined functions 
in the new file.

This would make it easy to add new inline functions, since it would only 
involve adding a new entry to this table and adding a function to 
generate the tree representation. It would also make it possible to 
later add extra info like size/cost which would help to determine 
whether its worth inlining a given call in a given situation, and this 
code could also decide whether to inline a given call based on whether 
an argument is static, for example.

>I initially wrote this with the intent of handling System.arraycopy,
>but ran aground before doing so.  I can remove these pieces of the
>code if you like.  For arraycopy, I've noticed that nearly half of all
>calls in the library use `0' for both offset arguments.  In cases like
>this we can eliminate some of the checking; my guess is if we inline
>too many checks it will outweigh the benefits.
>
I think it could certainly help to inline arraycopy in certain cases 
where most of the checks can be eliminated.

>We could also inline things like Math.sin, Math.cos, etc.  Doing that
>would require figuring out how to connect gcj to the builtin function
>infrastructure in gcc.  This might be tricky; for instance I think
>we'd want to fall back on calling `java.lang.Math.cos' instead of
>calling plain `cos' if the builtin is disabled.  (arraycopy suffers
>from this problem too, since we need __builtin_memcpy.)
>
I thought things like __builtin_cos would fall back on the library 
function if the builtin wasn't implemented? In any case it ought to be 
possible for GCJ to find out if a given builtin has been registered.


regards

Bryce