Calls to built-in functions are not Binary Compatible

[Andrew Haley]

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > > Bryce McKinlay writes:
 > >  > Doesn't this disable builtins mechanism entirely when 
 > >  > -findirect-dispatch is used?
 > >
 > > Yes.
 > >
 > >  > These builtins improve GCJ's performance significantly on some numeric 
 > >  > code (scimark, for example).
 > >
 > > So you don't use indirect dispatch, surely.
 > >   
 > To not use indirect dispatch would make the benchmark rather artificial 
 > - since most of the code we're running on libgcj these days uses the BC ABI.
 > >  > Wouldn't it be better to fix whatever problem is causing direct
 > >  > calls to be generated rather than disabling them completely?
 > >
 > > I don't understand your point -- this is the code that is causing
 > > direct calls to be made.  Built-in functions in gcc either generate
 > > direct calls or they get replaced by inline code.
 > 
 > Surely it is a bug, rather than a feature of this code, that it is 
 > causing direct (non-BC) calls to Java functions to be made. Direct calls 
 > to gcc/libc internal functions or inlining code is another matter.

gcc builtins are defined as either being optimized away (replaced with
some other code) or directly calling some library routine.  I suppose
it's not impossible to hack gcc's expander so that it generates
indirect dispatch code instead, but I doubt it's worth doing just for
these routines.

 > You could argue that it is not strictly "binary compatible" to inline, 
 > say, Math.min() - but realistically, the Math.* functions are well 
 > enough defined that they can always be safely inlined or converted to 
 > direct OS calls - since they are pure functions, that read only their 
 > arguments and do not depend on object layout and such.

Sure, that's true.  It would make sense to call the equivalent C
library functions where they exist.

What difference does this make to SciMark anyway?  I'm surprised it
makes much difference without -ffast-math.

Andrew.