Closed mbartling closed 3 years ago
Hi @mbartling,
thanks for reporting this. It looks like GCC does not properly recognize that the second parameter to __SXTB16_RORn
is a constant. Hence it reports the warning because a non-constant value cannot be used as an intermediate value (i.e. "i"(rotate)
).
We need to check how the GCC implementation of __SXTB16_RORn
can be fixed. Do you have any ideas?
Cheers, Jonatan
Honestly, I've only got a basic working knowledge of the GNU asm extensions. I'll do some deeper digging to see if there is anything I can do to help.
Thanks! -Michael
Hello @mbartling,
some GCC compiler experts advised to change the implementation to
#define __SXTB16_RORn(op1, rotate) \
({ \
uint32_t result; \
__ASM ("sxtb16 %0, %1, ROR %2" : "=r" (result) : "r" (op1), "i" (rotate) ); \
result; \
})
Could you please check if this solves then issue for you?
Cheers, Jonatan
Hi,
I suspect GCC is having trouble 'inlining' the rotate variable. It needs to be an immediate, so the expression must be compile-time known at the call-site. What Jonatan suggested should make that easier if __SXTB16_RORn is used with an immediate argument for 'rotate'. It might also help to beef up the optimization level.
Cheers, Andre
Hi @mbartling,
another slightly more elegant implementation might be:
__attribute__((always_inline)) static inline uint32_t __SXTB16_RORn(uint32_t op1, uint32_t rotate)
{
uint32_t result;
if (__builtin_constant_p (rotate) && ((rotate == 8U) || (rotate == 16U) || (rotate == 24U))) {
asm volatile ("sxtb16 %0, %1, ROR %2" : "=r" (result) : "r" (op1), "i" (rotate) );
} else {
result = __SXTB16(__ROR(op1, rotate)) ;
}
return result;
}
This should automatically boil down into a single "sxtb16 with intermediate ror" instruction if possible. Otherwise it combines plain sxtb with separate ror instruction.
Let me know if one of these solutions work for you and which one is the preferred one.
Cheers, Jonatan
Hey @JonatanAntoni @avieira-arm, both solutions seem to work and my code compiles CMSIS-NN/DSP to a static library successfully with a lightly modified toolchain file!
Thanks for all your help!
Please check the fix in 3551ea8 and close this issue if resolved. Thanks.
Looks good, sorry got buried in my notifications
Hello,
I've been working on including CMSIS-NN/DSP in a CMake project, and so far I've had pretty good luck with Cortex A configurations. However, when I set
ARM_CPU
tocortex-m*
I get the following issue with the core library:This only occurs when compiling on my Macbook, but does not occur when compiling in an arm64v8/ubuntu Docker container, even with the same GCC version:
Have you guys seen an issue like this before? Thanks!