BLD: fix uninitialized variable warnings from simd/neon/memory.h

[rgommers]

The warning was this, repeated many times:

In file included from ../numpy/_core/src/common/simd/neon/neon.h:76:
../numpy/_core/src/common/simd/neon/memory.h:56:56: warning: variable 'a' is uninitialized when used here [-Wuninitialized]
    a = vld1q_lane_s32((const int32_t*)ptr,            a, 0);
                                                       ^

I think the way I initialized the variable is idiomatic, but please double check (@Mousius or @seiko2plus?) since I'm not too familiar with this stuff.

Closes gh-25461

[Mousius]

As far as I can see, this emits the same output, initializing it whether you like it or not, so I would go ahead and merge this to fix the warning.

Ideally, we wouldn't have to initialize it, as we immediately overwrite it. Highway supports this for specific sections using macros; is that right @jan-wassenberg?
https://github.com/google/highway/blob/master/hwy/ops/arm_neon-inl.h#L937-L949

[rgommers]

Thanks for the review @Mousius.

Re macros with diagnostic pragmas: those are never really portable, and from a quick browse of the Highway code it looks pretty specific to MSVC and GCC. That means that you get swamped with warnings on compilers that aren't handled; Clang already tends to complain about the GCC macros it doesn't know about. So it's best to avoid these unless the performance impact is really large.

[Mousius]

@rgommers I guess the other option is to disable it blanketly for SIMD stuff then 🤔

[seiko2plus]

I think the way I initialized the variable is idiomatic, but please double check (@Mousius or @seiko2plus?) since I'm not too familiar with this stuff.

My bad. It's a false warning, it can be avoided by splats the first loaded element rather than initializing with zero, e.g.:

-int32x4_t a = vdupq_n_s32(0);
+int32x4_t a = vdupq_n_s32(*ptr);
-a = vld1q_lane_s32((const int32_t*)ptr,            a, 0);

[rgommers]

Ah thanks Sayed. Do you want to open a follow-up PR?

[seiko2plus]

Ah thanks Sayed. Do you want to open a follow-up PR?

Let me check the compiler behavior under optimization level 3 first, I think the compiler can optimize it out.

[jan-wassenberg]

A quick comment on pragmas: clang/gcc are largely the same, in rare cases they differ, for example the 'maybe-uninitialized' warning from the code you linked (only GCC has that one).
I agree it's generally better to initialize everything to the compiler's satisfaction, the cost seems minor.

[seiko2plus]

Let me check the compiler behavior under optimization level 3 first, I think the compiler can optimize it out.

No difference between the three versions the current, the previous, and the suggested one on clang, for GCC the current and the previous perform the same! initialize the returned vector with zero before loading. So it's totally fine to keep it as-is.

ref: https://godbolt.org/z/qr3sdvndn

[rgommers]

Awesome:)