VFP11 Veneers (GCC ARM)

Hey y'all --

I was just looking through the disassembly of a project I'm working on
around an ARM9 (NXP LPC3250) under the Code Red packaged GCC, and I
noticed that all of the floating point code is surrounded by a mess of
absolute branches to routines called __vfp11_veneer_N, for various
values of N. Each of those routines is nothing but a single
floating-point operation, followed by an absolute branch to a return
point __vfp11_veneer_N_r, which is always the instruction immediately
after the branch. For example:

/* Way up here */

8002978: eeb87a67 vcvt.f32.u32 s14, s15
800297c: eddf7a2d vldr s15, [pc, #180]
8002980: ea0008eb b 8004d34 <__vfp11_veneer_2>

08002984 <__vfp11_veneer_2_r>:
8002984: eddf7a2c vldr s15, [pc, #176]

/* And way down there */

08004d34 <__vfp11_veneer_2>:
8004d34: ee277a27 vmul.f32 s14, s14, s15
8004d38: eafff711 b 8002984 <__vfp11_veneer_2_r>

Anyone know what's going on in all of this, why the creation of all
these veneer functions, and how I can convince GCC to do otherwise? It
almost defeats the purpose of having hardware floating point support if
you keep crashing the pipeline to jump to and fro single instruction
veneers most (but not all) times you use them.

Thanks,
Rob

--
Rob Gaddi, Highland Technology
Email address is currently out of order

Rob Gaddi <> wrote:
> Anyone know what's going on in all of this, why the creation of all
> these veneer functions, and how I can convince GCC to do otherwise?

The point of the veneers is that by linking with the appropriate library
floating point can be performed in hardware or by user-space emulation.
Using the -mfloat-abi=softfp generates code that uses floating point
directly, but is still ABI-compatible. -mfloat-abi=hard/-mhard-float uses
a more efficient but incompatible ABI.

-a