Re: fixing ARM aeabi fesetround and friends

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 17 Apr 2009, Adam Goode wrote:

> Can we change the dl_hwcap conditional there to read the VFP attribute
> tag instead? Is this information still around at the point fesetround is
> called? I am trying to figure out how to load this information, it looks
> like something in dl-sysdep, but I'm not sure. Any hints are welcome.

I think the information will be merged by the linker to record that VFP is 
used by the final program if any object file uses it, which is not what 
you want here (you want to know whether any object file uses soft float - 
and you don't care about assembly files not using floating point at all 
...), and the information only goes in the static linker view of the final 
program, not the dynamic linker view, so isn't going to be readily 
accessible.

Arguably, you should only care anyway if some object uses software 
floating point *and* was compiled with -frounding-math (or with the 
FENV_ACCESS pragma, but that isn't implemented yet), and maybe the 
compiler should warn if you request -frounding-math for anything using 
software floating point that doesn't support rounding modes.  If you don't 
use -frounding-math (or the pragma) you are guaranteeing that code in the 
object will only ever execute with the default rounding mode.

One approach would be for the __aeabi_* software floating-point functions 
to use VFP is VFP is available at runtime, so that binaries built for 
software floating point will use the VFP instructions if available (slower 
than building them for VFP directly, faster than them using software).  
Since the information about availability of VFP isn't readily available in 
libgcc, one possibility might be:

* Make libgcc define the functions to use VFP if libgcc is built for VFP 
(defined (__VFP_FP__) && !defined (__SOFTFP__)).

* Build both VFP and soft-float copies of libgcc by using an appropriate 
compiler multilib configuration.

* Add HWCAP_ARM_VFP to HWCAP_IMPORTANT, so that a copy of the shared 
libgcc in /lib/vfp will be found at runtime by the dynamic linker.

* Arrange for the compiler to link with the shared libgcc by default so 
that the __aeabi_* functions come from shared libgcc and so can be 
replaced at dynamic link time.

But then you have dynamic linking overhead for calls to these functions, 
which isn't needed for most cases.  There is no perfect solution; the 
present code tries to help programs built for VFP without needing a 
separate VFP libc, at the expense of not telling programs using the 
unsupported soft-float plus rounding modes or exceptions combination that 
it is unsupported at runtime.  (See my suggestion above that the compiler 
should warn about this at compile time.)  C99 doesn't allow for all the 
combinations you can get for some targets of IEEE rounding modes and 
exceptions being supported for some types or under some conditions but not 
others.

-- 
Joseph S. Myers
joseph@codesourcery.com