On Wed, 2014-10-29 at 18:36 +0100, Julian Taylor wrote:
> the flags are only added to files which do the computations, the rest
> of the program should not have this flag, this should include the file
> that has the neon runtime check.
Makes sense, but then adding an intrinsic should be okay.
Reg
On 29.10.2014 13:06, Gert Wollny wrote:
>
> Regarding the use of intrinsics: AFAICS in configure.ac --with-neon
> always sets HAVE_NEON as define and adds the flag -mfpu=neon.
>
the flags are only added to files which do the computations, the rest of
the program should not have this flag, this
A few comments.
I'm not sure if the disassembly is the right one. Supposedly it is in a
function called "fftwf_guru64_kosherp", but it should be in
"really_have_neon".
There I would expect that the actual disassembly results in the the
signal SIGILL not being reset and "return 1" always being ex
On 29.10.2014 00:18, Edmund Grimley Evans wrote:
>> Though for Debian wouldn't it be enough to change the encoding to what
>> we are using?
>> possibly that could be automated by compiling a vand snipped and getting
>> the code with objdump during configure time.
>
> That sounds as if it could be
> > Is this signal-handling approach the best way of detecting NEON? The
> > following blog suggests using HWCAP, but I don't know if that would
> > work with the freebsd kernels:
>
> looks like a better way to do it, freebsd doesn't matter for us as we
> don't have a arm port of that.
> I don't k
On 28.10.2014 18:13, Edmund Grimley Evans wrote:
> Is this signal-handling approach the best way of detecting NEON? The
> following blog suggests using HWCAP, but I don't know if that would
> work with the freebsd kernels:
looks like a better way to do it, freebsd doesn't matter for us as we
don'
Source: fftw3
Version: 3.3.4-1.1
In simd-support/neon.c I found:
static int really_have_neon(void)
{
void (*oldsig)(int);
oldsig = signal(SIGILL, sighandler);
if (setjmp(jb)) {
signal(SIGILL, oldsig);
return 0;
} else {
/* parano
7 matches
Mail list logo
