I am curious why this happens though. The only thing I could think of was the
number is being constant folded in one case or being computed in one case via a
hardware intrinsic instead of libm in the other, but the generated C code looks
identical in both cases. Perhaps some previous register
On Wed, May 29, 2013 at 03:41:30PM -0500, Jim Ursetto wrote:
I am curious why this happens though. The only thing I could think of was
the number is being constant folded in one case or being computed in one case
via a hardware intrinsic instead of libm in the other, but the generated C
On Wed, May 29, 2013 at 10:53:32PM +0200, Peter Bex wrote:
It must be due to gcc spotting the call to sin() with a constant, then
replacing it with a precalculated constant in the generated machine code.
Urgh, this is exactly what you said. Sorry for the noise.
Cheers,
Peter
--
On May 29, 2013, at 3:53 PM, Peter Bex peter@xs4all.nl wrote:
The fpsin expands to a C inline call to sin(), whereas the sin() call
expands to a call to C_a_i_flonum_sin, which is not inlineable so it has
to issue a proper function call. This then goes through libm, which is
potentially
