NDK r4. unimplemented: -mfloat-abi=hard and VFP

[Stu]

Is there any reason why -mfloat-abi=hardfp is not supported with the
NDK's version of gcc?

I'm a little unhappy with:
- excessive library size (.so compiles to 15Mb (!), 1.1Mb after
running strip. Size is ~200Kb on other platforms.)
- floating point performance
and suspect that -mfloat-abi=softfp is to blame for both.

Running:
C:\android\android-ndk-r4\build\prebuilt\windows\arm-eabi-4.4.0\bin
\arm-eabi-gcc ... -march=armv7-a -mfloat-abi=hard -mfpu=vfp -
mtune=cortex-a8 ...
gives:
unimplemented: -mfloat-abi=hard and VFP

Has this just been disabled for the NDK's version of gcc? (Could I
install another gcc and expect this to work?)

Running:
cat /proc/cpuinfo
reports:
vfp and vfpv3
as available on my target device.

- Stu

[David Turner]

On Thu, Jul 8, 2010 at 11:04 AM, Stu <stuart....@gmail.com> wrote:

Is there any reason why -mfloat-abi=hardfp is not supported with the
NDK's version of gcc?

Yes, to ensure that ARMv5TE machine code generated with the NDK will run properly on ARMv7 CPUs.

-mfloat-abi only controls the way floating point values are passed during function calls, not which hardware instructions

are used to implement FPU operations.

With "softfp", floating point values are passed in core register pairs (i.e. r0-r1, r2-r3, etc..) during function calls.

With "hardfp", they are passed using FPU registers (i.e. d0, d1, d2, etc...)

The result is slightly slower function calls when FP values are used, but ensures that an ARMv7 Android device

can run unmodified binaries that were generated for ARMv5TE.

 

I'm a little unhappy with:
- excessive library size (.so compiles to 15Mb (!), 1.1Mb after
running strip. Size is ~200Kb on other platforms.)

This is most likely completely unrelated to -mfloat-abi

 

- floating point performance
and suspect that -mfloat-abi=softfp is to blame for both.

As I said, as long as you target armeabi-v7a, FPU instructions will be used to implement FP operations.

The exception would be certain functions in the math library.

 

Running:
  C:\android\android-ndk-r4\build\prebuilt\windows\arm-eabi-4.4.0\bin
\arm-eabi-gcc  ... -march=armv7-a -mfloat-abi=hard -mfpu=vfp -
mtune=cortex-a8  ...
gives:
  unimplemented: -mfloat-abi=hard and VFP

Has this just been disabled for the NDK's version of gcc? (Could I
install another gcc and expect this to work?)

Not as far as I know. Are you sure it's not something else than "hard" or "hardfp" ?

 

Running:
  cat /proc/cpuinfo
reports:
  vfp and vfpv3
as available on my target device.

That's right, and these will be used even with -mfloat-abi=softfp

 

- Stu

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Stuart Reynolds]

Thanks David,

My understanding for softfp is that I pay an overhead for:
- a function call
- a register read and a register write
for every floating point operation.

My code size will be bigger (maybe not much), and execution slower for
every FP operation even if the FPU in the implementation. Correct?

We've found that inlining our inner loops sped up our library 3x on
other platforms. I pretty sure having all fp operations as function
calls will result in very bad performance for us as it will remove
this inlining.

I'm mostly interested in profiling right now and can distribute softfp
and hard fp version of my .so if required. So, what to do?

- Stu

[David Turner]

On Thu, Jul 8, 2010 at 11:49 AM, Stuart Reynolds <s...@stureynolds.com> wrote:

Thanks David,

My understanding for softfp is that I pay an overhead for:
 - a function call

yes 

 - a register read and a register write
for every floating point operation.

no, FP operations are implemented as direct machine instructions if you target armeabi-v7a.

as I said earlier, this only affects parameter passing when performing function calls.

have a look at the disassembly if you don't believe me.

 

My code size will be bigger (maybe not much), and execution slower for
every FP operation even if the FPU in the implementation. Correct?

no, see above.

 

We've found that inlining our inner loops sped up our library 3x on
other platforms. I pretty sure having all fp operations as function
calls will result in very bad performance for us as it will remove
this inlining.

I'm mostly interested in profiling right now and can distribute softfp
and hard fp version of my .so if required. So, what to do?

the hardfp version of you .so will not be able to call *any* system library that

accepts a float or double as parameter, or returns one as a result on Android.

[fadden]

On Jul 8, 1:00 pm, David Turner <di...@android.com> wrote:
> have a look at the disassembly if you don't believe me.

I recommend you build it both ways and check the disassembly whether
you believe him or not. :-)

The only difference you should see is additional motion between the
hardware FP and general CPU registers. These operations are very fast
on ARM, so the overhead should be minimal.

You should NOT see any difference in what VFP instructions are
actually used, or what code gets inlined. If you are, you're probably
building for armv5te rather than armv7-a.