Calls to built-in functions are not Binary Compatible

Calls to built-in functions are not Binary Compatible

[Andrew Haley]

This happens with methods like Math.pow() which are converted to
builtins.  Unfortunately, this leads to direct calls to methods in
libgcj.  This breaks binary compatibility when we change gcj's name
mangling.  Which we just did.

:-(

Andrew.


2006-03-01  Andrew Haley  <aph@redhat.com>

	* builtins.c (check_for_builtin): Don't convert if
	flag_indirect_dispatch is set.

Index: builtins.c
===================================================================
--- builtins.c	(revision 111600)
+++ builtins.c	(working copy)
@@ -267,7 +267,9 @@
 tree
 check_for_builtin (tree method, tree call)
 {
-  if (! flag_emit_class_files && optimize && TREE_CODE (call) == CALL_EXPR)
+  if (! flag_emit_class_files 
+      && ! flag_indirect_dispatch
+      && optimize && TREE_CODE (call) == CALL_EXPR)
     {
       int i;
       tree method_arguments = TREE_OPERAND (call, 1);

Re: Calls to built-in functions are not Binary Compatible

[Andrew Pinski]

> 
> This happens with methods like Math.pow() which are converted to
> builtins.  Unfortunately, this leads to direct calls to methods in
> libgcj.  This breaks binary compatibility when we change gcj's name
> mangling.  Which we just did.

Aren't those direct function calls to libc functions though so
they really don't have an effect from gcj's name mangling?

-- Pinski

Re: Calls to built-in functions are not Binary Compatible

[Andrew Haley]

Andrew Pinski writes:
 > > 
 > > This happens with methods like Math.pow() which are converted to
 > > builtins.  Unfortunately, this leads to direct calls to methods in
 > > libgcj.  This breaks binary compatibility when we change gcj's name
 > > mangling.  Which we just did.
 > 
 > Aren't those direct function calls to libc functions

On some platforms the libc functions wouldn't be sufficiently
accurate.

 > though so they really don't have an effect from gcj's name
 > mangling?

They don't seem to be, no.  AFAIK the only purpose of the
builtins is to expose the possibility of constant propagation and
simplification, and (on x86) use of builtin instructions.

Given that libgcj has its own versions of these builtins, perhaps they
should be called directly rather than via the CNI stubs.  That would
be more efficient that what we do at the present time and solve the
mangling problem.

Andrew.

Re: Calls to built-in functions are not Binary Compatible

[Tom Tromey]

>>>>> "Andrew" == Andrew Pinski <pinskia@physics.uc.edu> writes:

>> This happens with methods like Math.pow() which are converted to
>> builtins.  Unfortunately, this leads to direct calls to methods in
>> libgcj.  This breaks binary compatibility when we change gcj's name
>> mangling.  Which we just did.

Andrew> Aren't those direct function calls to libc functions though so
Andrew> they really don't have an effect from gcj's name mangling?

No, but some of these do lower to things which aren't function calls
at all.  For instance take a look at how Double.longBitsToDouble is
handled.

Tom

Re: Calls to built-in functions are not Binary Compatible

[Bryce McKinlay]

Doesn't this disable builtins mechanism entirely when 
-findirect-dispatch is used?

These builtins improve GCJ's performance significantly on some numeric 
code (scimark, for example). Wouldn't it be better to fix whatever 
problem is causing direct calls to be generated rather than disabling 
them completely?

Bryce

Andrew Haley wrote:
> This happens with methods like Math.pow() which are converted to
> builtins.  Unfortunately, this leads to direct calls to methods in
> libgcj.  This breaks binary compatibility when we change gcj's name
> mangling.  Which we just did.
>
> :-(
>
> Andrew.
>
>
> 2006-03-01  Andrew Haley  <aph@redhat.com>
>
> 	* builtins.c (check_for_builtin): Don't convert if
> 	flag_indirect_dispatch is set.
>
> Index: builtins.c
> ===================================================================
> --- builtins.c	(revision 111600)
> +++ builtins.c	(working copy)
> @@ -267,7 +267,9 @@
>  tree
>  check_for_builtin (tree method, tree call)
>  {
> -  if (! flag_emit_class_files && optimize && TREE_CODE (call) == CALL_EXPR)
> +  if (! flag_emit_class_files 
> +      && ! flag_indirect_dispatch
> +      && optimize && TREE_CODE (call) == CALL_EXPR)
>      {
>        int i;
>        tree method_arguments = TREE_OPERAND (call, 1);
>   

Re: Calls to built-in functions are not Binary Compatible

[Andrew Haley]

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.

 > 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.

Andrew.

Re: Calls to built-in functions are not Binary Compatible

[Andrew Haley]

Andrew Haley writes:
 > 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.
 > 
 >  > 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.

One other possibility is perhaps to give these builtins entry names
that don't change whenever we change gcj's mangling.  But we don't
intend to changes gcj's mangling ever again, anyway.  So is this worth
doing at all?

Andrew.

Re: Calls to built-in functions are not Binary Compatible

[Bryce McKinlay]

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.

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.

Bryce

Re: 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.

Re: Calls to built-in functions are not Binary Compatible

[Tom Tromey]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> One other possibility is perhaps to give these builtins entry names
Andrew> that don't change whenever we change gcj's mangling.  But we don't
Andrew> intend to changes gcj's mangling ever again, anyway.  So is this worth
Andrew> doing at all?

I think one question here is, what kind of binary compatibility are
we really promising?

We can't promise binary compatibility in the general case.  And, I
don't think it is worth trying.

Instead I think we should only be promising that code compiled
-findirect-dispatch with the same compiler will follow the JLS binary
compatibility rules, and that beyond this we will only make a best
effort not to break things between GCC major releases.  I don't see
how we can do more, really.  For instance if calling conventions
change then we're just doomed.

In any case I think this particular patch is too big since it also
affects cases which won't result in an actual call, e.g. the
intBitsToFloat thing, which turns into a VIEW_CONVERT_EXPR.

Tom

Re: Calls to built-in functions are not Binary Compatible

[Andrew Haley]

Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> One other possibility is perhaps to give these builtins entry names
 > Andrew> that don't change whenever we change gcj's mangling.  But we don't
 > Andrew> intend to changes gcj's mangling ever again, anyway.  So is this worth
 > Andrew> doing at all?
 > 
 > I think one question here is, what kind of binary compatibility are
 > we really promising?
 > 
 > We can't promise binary compatibility in the general case.  And, I
 > don't think it is worth trying.
 > 
 > Instead I think we should only be promising that code compiled
 > -findirect-dispatch with the same compiler will follow the JLS binary
 > compatibility rules, and that beyond this we will only make a best
 > effort not to break things between GCC major releases.  I don't see
 > how we can do more, really.  For instance if calling conventions
 > change then we're just doomed.
 > 
 > In any case I think this particular patch is too big since it also
 > affects cases which won't result in an actual call, e.g. the
 > intBitsToFloat thing, which turns into a VIEW_CONVERT_EXPR.

Okay.  In that case, we can just drop it.

Andrew.

Re: Calls to built-in functions are not Binary Compatible

[Bryce McKinlay]

Andrew Haley wrote:
>  > 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.
>   

Right. I'm surprised that it is a Java library routine that is called 
here, in the case where the argument is not optimized away. Previously I 
was under the impression that it the appropriate equivalent function 
from fdlibm/libm would be called directly.

Since the Java Math.* calls all just call the appropriate fdlibm 
function, we can just have it call those directly - thus avoiding any 
issues with name mangling.

Bryce