https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234
--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Jeffrey Walton from comment #8) > Yeah, I tried to convert to the C/C++ pointer dereference pattern several > times as shown in the literature. I.e., this: > > byte x[16]; > uint8x16_p cc = (uint8x16_p)c; > *(uint8x16_p*) &x[0] = cc; That is the preferred way, in general. > Instead of this: > > byte x[16]; > vec_vsx_st((uint8x16_p)c, 0, x); > > It breaks a lot of our self tests for certain versions of a particular > compiler. Yeah, no doubt :-( But vec_vsx_st isn't even ABI. If it doesn't work well on some maintained GCC version, please tell me, or open a PR even. > I narrowed it down to the loads but I could not take it further > and develop a reduced case. I don't have the skill to untangle what is > happening in ppc asm at -O3. It seems the vec_add itself is handled incorrectly. We'll figure it out :-) > If you want to see something really obscene, then take a look at > https://github.com/weidai11/cryptopp/blob/master/ppc_simd.h#L251 . Heh. Well you have it nicely abstracted away to this one function :-) > (If you are talking about something else that is wrong or bad, then please > point it out.) Loads and stores should preferably be written as just assignments. That way, the compiler can figure out what is best to use for the selected ABI and CPU.
