Re: fixing ARM aeabi fesetround and friends

[Adam Goode <adam at spicenitz dot org>]

On 04/18/2009 11:35 AM, Daniel Jacobowitz wrote:
> IMO the right way to do this is either what Joseph described:
> 
>> 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).  
> 

I do like this way the best, at least at first. It seems much easier to
do a multilib implementation of the aeabi fp helper functions with VFP
than it is to modify the softfloat code.

Do you know the performance loss involved with forcing shared libgcc? Is
it a few cycles per floating point operation? I'm not familiar with how
efficient the dynamic linker is on ARM. Would people get mad at this?

> Or, take a compromise position that uses slower
> rounding-mode-sensitive softfp functions and save the rounding mode
> somewhere they can find it.  That, in turn, can be done two ways:
> either by making them read the VFP state if there is one, or by making
> even the VFP versions of the rounding mode functions set the software
> emulation rounding mode.
> 

This is also good to do, but probably harder than the multilib?


> There are some other ways we could implement the optimized functions,
> including the upcoming STT_GNU_IFUNC mechanism that Ulrich Drepper
> is adding to glibc.  That's simpler than having separate libraries,
> but does add some dynamic linker overhead.  Or, we could check at
> runtime in the soft-float functions whether a VFP unit is present.
> But that's got its own overhead.
> 

I'm guessing that since the presence of a VFP changes the selection of a
whole bunch of functions, that just having /lib/vfp instead of
STT_GNU_IFUNC (which is on a function-by-function basis) is easier.

Also, it seems that conditioning on VFP in the softfloat functions is
just as expensive as dynamically linking against libgcc, yes?


Thanks,

Adam

Attachment: signature.asc
Description: OpenPGP digital signature