dft test gets stuck during initialisation when hardware vector length is very long

[sh1boot]

If measure() fails here:

sleef/src/dft/dft.c

Line 1041 in ecb8936

if (p->bestPath[p->log2len] == 0) return 0;

then the init function falls into this loop, but makes no progress (N is always zero so length never decreases):

sleef/src/dft/dft.c

Lines 1222 to 1233 in ecb8936

	for(int level = p->log2len;level >= 1;) {
	int N = ABS(p->bestPath[level]);
	if (level == N) { level -= N; continue; }
	int i1 = 0;
	for(int i0=0;i0 < (1 << (p->log2len-N));i0+=p->vecwidth, i1++) {
	p->perm[level][i1] = 2*perm(p->log2len, i0, p->log2len-level, p->log2len-(level-N));
	}
	for(;i1 < (1 << p->log2len) + 8;i1++) p->perm[level][i1] = 0;
	level -= N;
	}

AFAICT it's measure() which is responsible for filling in p->bestPath, so if it fails I'm not sure what is meant to happen here.

I get it failing when I set qemu to emulate hardware with 1024-bit vector length on RISCV when running naivetestsp 10, but that code is not merged. Maybe it can also be reproducible with qemu and SVE.

I'm not sure why the earlier functions fail when the hardware is unusually wide, but since there's a code path that does something when they do I suppose it's a thing that's expected to happen.

[blapie]

Hello! Thanks for reporting. However, DFT is not officially supported yet for Risc-V. It is currently work in progress (#496) and it certainly isn't tested yet.
@luhenry is currently looking into #496

[sh1boot]

Yeah, I'm doing that RISCV stuff now. The trouble is that when I test with a 1024-bit wide vector register the code I linked to stops making sense.