Fix up RET instructions in sysdeps/i386/fpu

Fix up RET instructions in sysdeps/i386/fpu

Use NACLRET in order to pass the validator.

This was automated with:
perl -pi -e 's/^((\S+:)?\s*)ret(\s*)$/$1NACLRET$3/' $(find sysdeps/i386/fpu -name '*.S')

This fixes all cases of RET in libm.so and from fpu files in libc.so,
except for the trickier "RET $n" instructions.

I considered switching to C versions of these routines (e.g. in
sysdeps/ieee754/flt-32), but some are significantly more complicated
(a large function inside of a few instructions) and have probably
bitrotted through lack of use.  Using the C versions would involve
pulling in code such as __ieee754_rem_pio2f() from
sysdeps/ieee754/flt-32/e_rem_pio2f.c which is not mentioned in any
makefile and has probably been dead code for a while.

BUG=http://code.google.com/p/nativeclient/issues/detail?id=876
TEST=run_float_math_test (with another change applied to fix SETUP_PIC_REG)

[pasko-google - do not use, 2010-09-30 09:39:37]

This LGTM as a specific improvement to make more code pass validation.

Though I would like to raise a question (to Victor and Mark) on whether we want
to expose this to external developers now. Regardless of the answer I think you
should commit this today.

As far as I can see this exposes a lot of math functions with their x87
implementations. So if once we want to make things fast on Atom, we would have
to replace this stuff with SSE2 variants (and some of it would be hard to
implement whether it's C or SSE2). Should we rather be more restrictive now and
not export these things until we are specifically asked to do so? This affects
portability of many applications, of course, but how important is that?

How much of this functionality can be quickly and safely replaced by C versions
or SSE versions (including from newer glibc)?

[khim, 2010-09-30 10:20:14]

All these functions are implementable in C: they are part of POSIX standard so
they are implementable on all popular CPUs.

Of course if we'll want to replace these functions with x87-free variants it'll
be sizable work.

[Mark Seaborn, 2010-09-30 11:16:46]

On 2010/09/30 09:39:37, pasko wrote:
> This LGTM as a specific improvement to make more code pass
> validation.
>
> Though I would like to raise a question (to Victor and Mark) on
> whether we want to expose this to external developers
> now. Regardless of the answer I think you should commit this today.

OK, committed.

> As far as I can see this exposes a lot of math functions with their
> x87 implementations. So if once we want to make things fast on Atom,
> we would have to replace this stuff with SSE2 variants (and some of
> it would be hard to implement whether it's C or SSE2). Should we
> rather be more restrictive now and not export these things until we
> are specifically asked to do so? This affects portability of many
> applications, of course, but how important is that?

Can you file an issue for this?  Would I be right in thinking that x87
is just slow on Atom?

> How much of this functionality can be quickly and safely replaced by
> C versions or SSE versions (including from newer glibc)?

The first function I hit while running run_float_math_test was
finitef() (sysdeps/i386/fpu/s_finitef.S), which has a nice and simple
C implementation in sysdeps/ieee754/flt-32/s_finitef.c.

But later functions have more complex C implementations and I don't
know enough about floating point maths to know how to test this
properly or feel confident in enabling the C versions.

Mark