A pow(10.0, x) where x has the hex equivalent of 0xc022247c7a9c48f9l
needs 4000 times longer as x equal 0xc022247c7a9c4800l, which is nearly
the same value.

This happens on x86_64 Linux. I have tested it with the current git tree
and GLIB 2.19, but the behavior can also reproduced on an old EGLIBC
2.12 32 bit PowerPC Linux system.

The origin the fdlibm pow() function does not show this performance
impact, but is nearly three times slower as the best case libm execution
time. The result of the function call are the same.

As i figured out the value 0xc022247c7a9c48f9l run into the __slowpow()
branch, where 0xc022247c7a9c4800l does bypass this branch.

A "perf stat -e instructions" show that the 0xc022247c7a9c48f9 value
needs round about 1505962 instructions, the 0xc022247c7a9c4800l needs
only 385 instructions.

On the old PowerPC device the execution time is 1 us vs. 5000 us.

This makes pow() not very useable in a realtime environment.

Maybe the exp() has the same problem.

IMHO it is a bug since the origin fdlibm does not have this performance impact.

- Stefani

Attach is a simple test program to reproduce the issue.