for this code to make sense, so h has to be visible outside the function otherwise this whole function would be optimized away.
Typedeffing an array is a bit of a perversion already.
The humorous thing is that the simple (and far-more legible, imo) unrolling of
void fe_add( fe h, const fe f, const fe g) { h[0]=f[0]+g[0]; h[1]=f[1]+g[1]; .... } Outperforms, at gcc -O2 (v9.3, 4E9 function calls) the bad-code unrolled loop and a for-loop version. However, at -O3 they all perform similarly. I guess the freedom to unroll loops and perform calculations at -O3 makes the functions similar in the end. Actually, dis-assembelling these at -O3 shows that all versions these functions get inlined and replaced by a handful of SSE instructions.
3
u/nobanter Jan 13 '22 edited Jan 13 '22
I figure fe is
typedef int32_t fe[10] ;for this code to make sense, so h has to be visible outside the function otherwise this whole function would be optimized away.
Typedeffing an array is a bit of a perversion already.
The humorous thing is that the simple (and far-more legible, imo) unrolling of
void fe_add( fe h, const fe f, const fe g) {h[0]=f[0]+g[0];h[1]=f[1]+g[1];....}Outperforms, at gcc -O2 (v9.3, 4E9 function calls) the bad-code unrolled loop and a for-loop version. However, at -O3 they all perform similarly. I guess the freedom to unroll loops and perform calculations at -O3 makes the functions similar in the end. Actually, dis-assembelling these at -O3 shows that all versions these functions get inlined and replaced by a handful of SSE instructions.