I've some difficults to understand because the piece of code impacted by this patch is only use if HAVE_ARM_NEON_H is true. Then I suppose if the CPU is an ARM but has no neon this test is false and then this part is not used. It's seems logical because c and asm files added in this section are neon related. No?
Gwen On Fri, 10 Nov 2017 06:41:10 -0500 Philip Balister via USRP-users <usrp-users@lists.ettus.com> wrote: > On 11/10/2017 04:11 AM, Ron Economos via USRP-users wrote: > > I guess this is a little late, but you can pass in compiler flags > > on the command line with -DCMAKE_CXX_FLAGS. For example: > > > > cmake -DCMAKE_CXX_FLAGS:STRING="-mfloat-abi=hard -mfpu=neon > > -mtune=cortex-a15" ../ > > That would be the preferred way. The patch mentioned assumes that > anytime you are using a compiler with the neon.h header file, the SoC > you are compiling for has a neon unit. This is a bad assumption. There > are a few examples of SoC's around that do not have a neon unit. Now > UHD will generate neon and create runtime failures. > > Bottom line, in the ARM world, you cannot test compiler features to > figure out what features the runtime system has. > > Philip > > > > > > Ron > > > > On 11/10/2017 12:07 AM, Gwenhael Goavec-Merou via USRP-users > > wrote: > >> Hello, > >> > >> maybe this : https://github.com/EttusResearch/uhd/pull/135 > >> will help you > >> > >> Gwen > >> > >> On Fri, 10 Nov 2017 00:29:25 -0600 > >> Kevin McGuire via USRP-users <usrp-users@lists.ettus.com> wrote: > >> > >>> I was able to get the compiler flags passed in so that the check > >>> for the header arm_neon.h passes. I added it to the CMakeList > >>> root file with SET(CMAKE_CXX_FLAGS, "${CMAKE_CXX_FLAGS} > >>> -mfloat-abi=softfp -mfpu=neon"). > >>> > >>> Then, it would detect neon. However, I spent considerable time > >>> cleaning up whatever package problems I had since I ended up with > >>> a bunch of weird errors. > >>> > >>> Once I straightened my packages up (Debian), it is compiling with > >>> neon! And, hopefully, it will actually use the ARM neon routines. > >>> > >>> On Thu, Nov 9, 2017 at 3:22 AM, Kevin McGuire <kmcg3...@gmail.com> > >>> wrote: > >>> > >>>> I have noticed that neon support for the converter is not > >>>> enabling. The CMakeError.log has this output. I am not certain > >>>> as I am not really familiar with ARM and NEON, but I checked my > >>>> CPU and it does support it. Also, the error message below is > >>>> saying it is just a matter of passing certain flags. > >>>> > >>>> /mnt/extra/usr/lib/gcc/arm-linux-gnueabihf/4.8/include/arm_neon.h:32:2: > >>>> error: #error You must enable NEON instructions (e.g. > >>>> -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h > >>>> #error You must enable NEON instructions (e.g. > >>>> -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h > >>>> > >>>> Normally, I would just fix it myself and move forward, but me and > >>>> CMake mix like oil and water. It is kind of embarrassing but I > >>>> swear it never does what I want it do - such as adding a darn > >>>> flag. I even tried to force the options, lol, and all be danged > >>>> if CMake finds some way to error. > >>>> > >>>> Will work on this tomorrow, but if anyone has a solution I am all > >>>> ears. If not then no problem and I will reply when I figure it > >>>> out. > >>>> > >>>> This came about when I noticed what really seemed like abnormally > >>>> high CPU usage on my ARM code for a simple shuffling of data out > >>>> of the network packets. I traced what I felt like was the biggest > >>>> possible hot spot to the converter routine. Anyway, that is my > >>>> plan right now, to see if NEON might help if the converter is > >>>> having to swap byte order. > >> _______________________________________________ > >> USRP-users mailing list > >> USRP-users@lists.ettus.com > >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >> > > > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
