[SVE] necessary write is dropped

[eustas]

Godbolt: https://godbolt.org/z/5cjfqh6K1

When WANT_BUG is 0 everything works as expected.
When WANT_BUG is 1 result of rng.Fill is dropped, consequently result is undefined garbage.

Compare disassembly of nevermind::N_SVE2_128::BugCore(unsigned int, unsigned long); when WANT_BUG is 0 it is 3 instructions longer; 2 of those are calculating the result (add z4.d, z2.d, z3.d) and storing it (st1d {z4.d}, p0, [x8]).

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Eugene Kliuchnikov (eustas)

Godbolt: https://godbolt.org/z/5cjfqh6K1

When WANT_BUG is 0 everything works as expected.
When WANT_BUG is 1 result of rng.Fill is dropped, consequently result is undefined garbage.

Compare disassembly of nevermind::N_SVE2_128::BugCore(unsigned int, unsigned long); when WANT_BUG is 0 it is 3 instructions longer; 2 of those are calculating the result (add z4.d, z2.d, z3.d) and storing it (st1d {z4.d}, p0, [x8]).

[eustas]

More correct behaviour with WANT_BUG=0, when actual result is used: https://godbolt.org/z/7xYfcMxzv.
Overall, looks like incorrect aliasing problem (because speculative memcpy that is actually optimised out helps).

[MacDue]

This looks like it's probably an invalid input:

#if WANT_BUG
    HWY_ALIGN uint64_t batch[Rng::N];
#else
   // ...
#endif 

const auto bits = Load(du, reinterpret_cast<const uint32_t*>(batch) + i);

I think the compiler is allowed to assume pointers of uint64_t* and uint32_t* won't alias (as they're different types). When doing these kinds of bitcasts you tend to need the memcpy to a new buffer (of the target type), to ensure the code is correct.

[eustas]

But the problem happens only when variable is on stack and the target is SVE2 with 128-bit vectors.
Other targets are fine (SVE, NEON, multitude of Intel SIMDs); placing batch on heap also works fine.

[eustas]

Also compiler knows that batch and batch32 are aliased and thus removes no-op memcpy.

(though, adding -fno-strict-aliasing help, it feels to be inconsistent: as I have mentioned this problem does not occur on other targets)