|
|
@@ -6,7 +6,7 @@ TL;DR summary
|
|
|
* Use only NEON instructions, or VFP instructions that don't rely on support
|
|
|
code
|
|
|
* Isolate your NEON code in a separate compilation unit, and compile it with
|
|
|
- '-mfpu=neon -mfloat-abi=softfp'
|
|
|
+ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
|
|
|
* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
|
|
|
NEON code
|
|
|
* Don't sleep in your NEON code, and be aware that it will be executed with
|
|
|
@@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special care is taken.
|
|
|
Therefore, the recommended and only supported way of using NEON/VFP in the
|
|
|
kernel is by adhering to the following rules:
|
|
|
* isolate the NEON code in a separate compilation unit and compile it with
|
|
|
- '-mfpu=neon -mfloat-abi=softfp';
|
|
|
+ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
|
|
|
* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
|
|
|
into the unit containing the NEON code from a compilation unit which is *not*
|
|
|
built with the GCC flag '-mfpu=neon' set.
|