Re: [Buildroot] [PATCH 1/4] Revert "configs/olimex_a33_olinuxino: use NEON+VFPv4 as FPU strategy"

[Giulio Benetti <giulio.benetti@benettiengineering.com>]

Hi Arnout, Yann, Thomas, All,

On 16/08/22 22:46, Arnout Vandecappelle wrote:
> 
> 
> On 15/08/2022 17:48, Giulio Benetti wrote:
>> The gcc man page states that specifying Neon as part of the fpu setting
>> has no effect, unless the -funsafe-math-optimizations is also specified,
>> because Neon is not compliant with IEEE 754:
>> ```
>>      If the selected floating-point hardware includes the NEON extension
>>      (e.g. -mfpu=neon), note that floating-point operations are not
>>      generated by GCC's auto-vectorization pass unless
>>      -funsafe-math-optimizations is also specified. This is because NEON
>>      hardware does not fully implement the IEEE 754 standard for
>>      floating-point arithmetic (in particular denormal values are treated
>>      as zero), so the use of NEON instructions may lead to a loss of
>>      precision.
>> ```
>>
>> -funsafe-math-optimizations must be explictly specified per package to
>> really use NEON as FPU,
> 
>   That's not true. The statement above is just about auto-vectorization, 
> but it's still possible to use intrinsics or inline assembly to use NEON 
> in your code. I don't know what exactly happens with those if we specify 
> -mfpu=vfpv4-d16, but I expect that it will not compile those. So 
> packages will discover that neon is not supported on the target CPU, 
> while actually it is.
> 
>   Note that that unsafe-math-optimizations thing was exactly the reason 
> why we thought it was OK to allow -mfpu=neon-vfpv4 to begin with - GCC 
> is not going to generate invalid code out of the box.


My bad here. I've written a bad commit log and that phrase is not
correct, you're right. If BR2_ARM_FPU_NEON_VFPV4 is enabled then
processor will use NEON as FPU but with a loss of precision and
without auto-vectorization BUT only if -funsafe-math-optimizations is
passed(very hard to find a package with that flags passed).
So the idea *was* to *not* use VFPV4+NEON by default on defconfigs and
then enable per defconfig, depending on SoC FPU implementation,
the right VFPV4: D16 or D32.
Leaving as it is(with NEON enabled) floating point code generated
will miss some FPU acceleration since IEEE 754 is not met(*I thought*).

BUT then I've found what ARM recommends: [1]

I think we should follow what they recommend. And there is a good
table to follow, of course depending on per SoC FPU implementation if
something is optional according to the cortex-Ax model.
For example they suggest BR2_ARM_FPU_NEON_VFPV4(-mfpu=neon-vfpv4) for
Cortex-A7 if NEON(SIMD) is supported. So yes, these reverts then
don't make sense.

What I understand *now* then is that the loss of precision due to the
fact that *NEON* is not fully IEEE 754 is true only if 
-funsafe-math-optimizations flag is passed.

Otherwise I don't think official ARM website would suggest such table,
right?

Here[3] they clarify it and the table[1] has more sense.
They state:
```
However, the compiler might *not vectorize* the code when you expect it 
to. There are various reasons for this:

     Optimization level for the vectorizer

     *IEEE compliance.*
```

And here[4] a set of command line examples.

The point the yes, it seems to be only about auto-vectorization.

So here I ask myself(and you): do we have better performances with
NEON or without NEON if present even if we loose auto-vectorization?

NOTE: -Ofast has the same effect of -ffast-math that relaxes the rules
and enable vectorization. So that will break IEEE 754 standard anyway,
not only -funsafe-math-optimizations.
So this already happens.

So, do we really need to be so strictly compliant to IEEE 754?
NEON unit seems to "save power and maximize the performance" compared
to VFPV4 as pointed here[3].

>> but it's something that is left to the user as
>> well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
>> BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
>> offending patch.
> 
>   I could be wrong, but doesn't the availability of SIMD imply that 
> there are 32 DP registers?

Judging from the link above:
```
VFPv3 and VFPv4 implementations provide 32 double-precision registers. 
However, when NEON unit is not present, the top sixteen registers 
(D16-D31) become optional. This is shown by the -d16 in the option name, 
which means that the top sixteen D registers are not available
```
Yes, FP+SIMD implies 32 double precision registers. Indeed in the table,
on the column "FP + SIMD" there is no "-d16" passed. That only happens
in the column "FP only".

Then I would like to adjust any defconfig according to SoC's FPU
implementation according to that table. What about this?

The other chance would be directly testing on different SoCs
what happens with a program/package that uses floating point datas.
But that table talks pretty clear IMHO. And anyway I have planned
to bump all Olimex Allwinner boards as well as Asus Tinker and
Amarula Vyasa. So I'll have the chance to test it.
So:
cortex-A7
cortex-A8
cortex-A17(the table doesn't talk about that but here[2] we can
see that A12/A15/A17 have both VFPV4+NEON so I can follow the column
for A15)

Actually I don't have boards with A5 and A9. So maybe we can ask to
Microchip SAMA5 maintainers and NXP i.MX6 maintainers to give a try
the next time they bump u-boot/linux.

Which package could be the right one to see if everything works
smooth instead of hanging because of FPU illegal instruction?

Hope I'm on the right direction and at least providing some new
informations. It's pretty intricate this part.

I wait for your thoughts on this. Sorry if something is not that clear,
I'm trying to clarify myself!

Thank you!

[1]: 
https://developer.arm.com/documentation/den0018/a/Compiling-NEON-Instructions/GCC-command-line-options/Option-to-specify-the-FPU
[2]: https://en.wikipedia.org/wiki/Comparison_of_ARMv7-A_processors
[3]: 
https://developer.arm.com/documentation/den0018/a/Compiling-NEON-Instructions/GCC-command-line-options/Vectorizing-floating-point-operations
[4]: 
https://developer.arm.com/documentation/den0018/a/Compiling-NEON-Instructions/GCC-command-line-options/Example-GCC-command-line-usage-for-NEON-code-optimization

Best regards
-- 
Giulio Benetti
Benetti Engineering sas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot