Migration guide to use new linker-based code size optimization

[escherstair]

I see the new section Code Size in README.md that states:

Previous versions of the library were using compilation directives to control the code size. It was too complex and not available in case CMSIS-DSP is only delivered as a static library.

Now, the library relies again on the linker to do the code size optimization. But, this implies some constraints on the code you write and new functions had to be introduced.

If you know the size of your FFT in advance, use initializations functions like arm_cfft_init_64_f32 instead of using the generic initialization functions arm_cfft_init_f32. Using the generic function will prevent the linker from being able to deduce which functions and tables must be kept for the FFT and everything will be included.

There are similar functions for RFFT, MFCC ...

If the flag ARM_DSP_CONFIG_TABLES is still set, you'll now get a compilation error to remind you that this flag no more have any effect on code size and that you may have to rework the initializations.

The general idea is clear, but the steps needed to migrate a legacy project that uses all the old compiler directives is not.
As an example, my project uses all the following compiler directives

ARM_MATH_LOOPUNROLL
DISABLEFLOAT16
ARM_DSP_CONFIG_TABLES
ARM_FAST_ALLOW_TABLES
ARM_FFT_ALLOW_TABLES
ARM_TABLE_SIN_F32
ARM_TABLE_TWIDDLECOEF_F32_2048
ARM_TABLE_BITREVIDX_FLT_2048
ARM_TABLE_TWIDDLECOEF_RFFT_F32_4096
ARM_TABLE_SQRT_Q15
ARM_TABLE_SQRT_Q31

I cannot use anymore ARM_DSP_CONFIG_TABLES and I get the error.
I know in advance that I need a real FFT over 4046 samples, and so I have to replace my arm_rfft_fast_init_f32 with arm_rfft_fast_init_4096_f32 (if I'm right).
But what about all the other compiler defines?
Should I remove all of them (refactoring in some way my source code)?

Can you provide a migration guide for this breaking change feature?

[christophe0606]

@escherstair You're right. It needs more documentatiom.
You only need to keep

ARM_MATH_LOOPUNROLL
DISABLEFLOAT16

[escherstair]

Thanks @christophe0606
I'll wait for the documentation.
In the meanwhile, should I change my source code for every compiler define I remove?
Or is arm_rfft_fast_init_4096_f32 the only change needed?

[christophe0606]

Normally arm_rfft_fast_init_4096_f32 is the only change. Like that the linker js able to infer what you really use and can optimize out the code and tables not needed.

[jonnor]

Note that some tables do not actually yield savings right now, even if using the dedicated initialization function. In particular, using the arm_rfft_init_LENGTH_q15 functions will still always take maximum amount of space. Ref issue: #25

[christophe0606]

Although it is not really a migration guide, the Doxygen documentation has been improved and give more details about the removal of old compilation flags and the new linker based mechanism.