volk_cpu.tmpl.c on non-X86 cpus

[michael-roe]

Looking at the code, it treats anything starting with "neon" as an ARM feature, and everything else as x86.

I haven't tried running it yet, but I think this will break when run on any architecture that isn't ARM or X86.

(I am going to upstream some MIPS fixes to cpu_features, and I have several different MIPS workstations to test on. If I have time and I'm feeling brave enough, I might try writing a RISC-V port of CPU features.)

I think we may need a more general mechanism to say which features are part of which architecture.

=======

there's another problem with the code in this file. It assumes that the total number of cpu features, across all architectures, is less than or equal to the number of bits in an int. This is so it can set a bit in an int for each feature. This is not going to scale when volk is ported to more architectures. A bit for each feature of the architecture it's been compiled for would fit. A bit for every feature of every architecture volk has been ported to will eventually not fit.

[jdemel]

volk/tmpl/volk_cpu.tmpl.c

Lines 101 to 108 in af69c60

	unsigned int volk_get_lvarch() {
	unsigned int retval = 0;
	volk_cpu_init();
	%for arch in archs:
	retval += volk_cpu.has_${arch.name}() << LV_${arch.name.upper()};
	%endfor
	return retval;
	}

I had a closer look at your second comment. I assume you refer to the volk_get_lvarchfunction. It is only used involk.c`, e.g.

volk/tmpl/volk.tmpl.c

Line 48 in af69c60

if(!(volk_machines[i]->caps & (~volk_get_lvarch()))) {

It is related to this field:

volk/tmpl/volk_machines.tmpl.h

Line 34 in af69c60

const unsigned int caps; //capabilities (i.e., archs compiled into this machine, in the volk_get_lvarch format)

Currently, numbers up to 23 are used. This implies that 23 bit are used. It'd be better to start looking for a better solution here.

[jdemel]

Since we use cpu_features with MIPS etc. now, and things still work, I suggest to close this issue.