frexp function misoptimization

frexp function misoptimization

[Jeremy Sanders]

I notice on x86_64 Linux with gcc-4.1.2, that if I make a call to frexp()
from math.h, this function is not inlined in the assembly output
(with -O2). I've tried -ffast-math as well.

As this function could be trivially inlined (it's just a matter of getting
the correct bits from the stored number), is this a gcc misoptimization or
is glibc the culprit?

Here's a sample program:

---------------------------
#include <math.h>

int main()
{
  double x = 1.;
  int i;

  x = frexp(x, &i);
  return 0;
}
---------------------------

$ gcc -O2 -S test.c
$ cat test.s
...
       call    frexp
...

Thanks

Jeremy

-- 
Jeremy Sanders <jss@ast.cam.ac.uk>   http://www-xray.ast.cam.ac.uk/~jss/

Re: frexp function misoptimization

[Ian Lance Taylor]

Jeremy Sanders <jss@ast.cam.ac.uk> writes:

> I notice on x86_64 Linux with gcc-4.1.2, that if I make a call to frexp()
> from math.h, this function is not inlined in the assembly output
> (with -O2). I've tried -ffast-math as well.
>
> As this function could be trivially inlined (it's just a matter of getting
> the correct bits from the stored number), is this a gcc misoptimization or
> is glibc the culprit?

It's just that nobody got around to it.  As it happens, inlining of
frexp is a new optimization in gcc 4.3.

Ian

Re: frexp function misoptimization

[Jeremy Sanders]

Ian Lance Taylor wrote:

> It's just that nobody got around to it.  As it happens, inlining of
> frexp is a new optimization in gcc 4.3.

Great! I apologise about saying "misoptimization" in my previous email - I
meant to say "missing optimization" but I haven't had enough coffee..

Thanks

Jeremy

-- 
Jeremy Sanders <jss@ast.cam.ac.uk>   http://www-xray.ast.cam.ac.uk/~jss/
X-Ray Group, Institute of Astronomy, University of Cambridge, UK.