Comment 13 for bug 303232

On Thu, 2009-01-22 at 15:58 +0000, Loïc Minier wrote:
> [Ack, I do understand there's a performance hit when gong via libgcc,
> but I was hoping this could be a good compromise between not using
> hardware FPU at all and generating traps on systems without FPU.]

I haven't looked but I think there is more work here as the softfloat
function in libgcc would need to be rewritten to use VFP instructions.
Compiling with -mfpu=vfp simply ignores those functions.

> Concerning libm as a candidate for opts: libm is in libc which is
> definitely a candidate for an optimized version; for example with have
> an i686 version for the i386 arch which provides an alternate libm:
> http://packages.ubuntu.com/jaunty/i386/libc6-i686/filelist

Could we not have the same for other packages that would benefit from
VFP? I'm not too familiar with the version conflicts in the .deb
packages but, for example, could we have something like a dummy
openoffice package which depends on either openoffice-softfp or
openoffice-vfp?

> The mainline kernel (we're primarily looking at 2.6.28 in jaunty)
> supports some traps out of the box, but only:
> - to handle VFP state saving and restoring across context switches (I
> guess this is to avoid saving/restoring the FPU regs when the switched
> to context doesn't need that)
> - to emulate some corner cases not supported by all hardware FPUs
> - on math errors
> and we don't need to patch anything to get the above when we're using
> VFP instructions in programs. Perhaps we need to turn on some kernel
> CONFIG_s in our armel flavours though?

You need to have CONFIG_VFP on. This could always be on by default as
the kernel checks for the hardware feature before enabling the
corresponding hwcap bit.

> Otherwise, the mainline kernel can't emulate the base set of VFP
> instructions which ARMv5 and v6 cores with a FPU support on systems
> which lack a FPU (such as the Xscale example); we could perhaps patch
> this in, but it's not wanted in the mainline because it's too slow. I
> take it that the response from Linux developers is that we're supposed
> to not use VFP instructions in userspace on systems without a FPU?

Probably that's the reason as we now have a fast softfloat
implementation. This is the relevant thread (though not many opinions):

http://thread.gmane.org/gmane.linux.ports.arm.kernel/47219

> I didn't find any flags in the gcc man page about VFPv2 or v3: I guess
> one can only tell gcc to generate instructions for the full VFP set or
> not at all.

By default, with -mfpu=vfp, the compiler generates VFPv2 code and I
think that's what should be used as VFPv3 only comes with ARMv7.