Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?

[Philip Balister]

Some quick notes:

1) the mfloat_abi option controls which ARM abi is used for function
calls. hard lets the compiler return floats in "NEON" registers. soft
just means they are returned as addresses or something. The setting must
match the one used to build the root file system you are running.

2) Any feature detection that probes settings on the build machine is
broken. It will lead to failures for people cross compiling. I basically
try to force all instruction set settings for gnuradio for just this reason.

Philip

On 08/07/2013 05:05 PM, Monahan-Mitchell, Tim wrote:
> Hi, Marcus
> 
>> On 08/07/2013 09:48 PM, Monahan-Mitchell, Tim wrote:
>>> Because of the 'abi_softfp' test failing on my x86, I decided I did not 
>>> need to re-build the ARM tool chain to support soft ABI to try and help 
>>> Volk. Is that still correct? (I have been able to build and run gnuradio 
>>> without the soft flag just fine).
>> I don't think -mfloat_abi=softfp (or even =soft) applies to x86; I think I 
>> remember the equivalent flag being something along the ways of 
>> -msoft-float... Or am I misunderstanding you and you talk about 
>> cross-compiling on x86 for arm?
> 
> In my volk travels to answer this email thread's question, I was comparing 
> what cmake did on my x86 (where there is more volk support) to what cmake 
> does on my ARM target. I noted that both had "-- Performing Test 
> have_mfloat_abi_softfp - Failed", hence my conclusion that softfp was not a 
> requirement for volk.
> 
> <snip>
> 
>> 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.
> 
>> So it might make sense to include -funsafe-math-optimizations, if 
>> vectorize-with-neon-quad does not do that implicitly.
> 
> Yes, I have -funsafe-math-optimizations and the cmake test for it passes: " 
> Performing Test have_funsafe_math_optimizations - Success"
> 
> Thanks,
> Tim
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>