const-qualify other FFT functions

[escherstair]

Some years ago I've already opened an issue with the request of const-qualifying parametrs for FFT functions as much as possible.
Some of them have been const-qualified with commit 89fa43d.

Other parameters could be const-qualified in the same way:

CMSIS-DSP/Source/TransformFunctions/arm_cfft_f32.c

Line 849 in 47a832f

static void arm_cfft_radix8by2_f32 (arm_cfft_instance_f32 * S, float32_t * p1)

to

static void arm_cfft_radix8by2_f32 (const arm_cfft_instance_f32 * S, float32_t * p1)

CMSIS-DSP/Source/TransformFunctions/arm_cfft_f32.c

Line 963 in 47a832f

static void arm_cfft_radix8by4_f32 (arm_cfft_instance_f32 * S, float32_t * p1)

to

static void arm_cfft_radix8by4_f32 (const arm_cfft_instance_f32 * S, float32_t * p1)

If @llefaucheur is interesed I can open a PR.

[llefaucheur]

The problem is the validation time (clang, gcc, ac6, neon, m0, helium, m7 etc ...), which would be justified for a big change or a big gain in cycles. Your proposal is kept, thank you.

[christophe0606]

@escherstair I am currently prioritizing bugs and things that break in CMSIS-DSP because my bandwidth is currently taken elsewhere.

I agree that such an improvement would be nice to have.

But I'll need to check if there is a reason why it has not been done so far. I try to keep same API for all architectures (including Neon) and they have some different implementation requests. Perhaps const is possible for some implementation but not for others.

But unfortunately, I won't be able to look at it soon

Thanks for always suggesting improvements ! We listen even if we are not always reacting as quickly as we would like.