[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78303 kelvin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from kelvin at gcc dot gnu.org --- Our plan is to deprecate the -maltivec=be option.
[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78303 --- Comment #4 from Segher Boessenkool --- If -maltivec=be is not used, I support removing it. Deprecating it with a warning on use will show if anyone care enough to tell us they do use it ;-)
[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78303 --- Comment #3 from Bill Schmidt --- The memory layout is correct. It should not change regardless of endianness settings. (The byte order of each element is dependent upon the fundamental endianness, but the order of array elements with respect to one another is always the same. On a POWER8, -maltivec=be means to load the array with lxvd2x, whereas -maltivec=le means to load the array with lxvd2x and adjust with a swap instruction. On a POWER9, lxvx can be used when the -maltivec setting matches the fundamental endianness (so is correct on BE and LE by default). Using -maltivec=be on an LE system requires using lxvd2x or similar (depending upon element size). I am tempted to deprecate -maltivec=be in GCC 8 and remove support for it in GCC 9. This behavior is optional and was designed primarily to support certain libraries that are not supported by GCC anyway. Keeping it consistent is a time sink with little benefit...
[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78303
kelvin at gcc dot gnu.org changed:
What|Removed |Added
CC||kelvin at gcc dot gnu.org
--- Comment #2 from kelvin at gcc dot gnu.org ---
The gcc.pdf documentation states the following:
-maltivec=be
Generate AltiVec instructions using big-endian element order, regardless
of whether the target is big- or little-endian. This is the default
when targeting a big-endian platform. The element order is used to interpret
element numbers in AltiVec intrinsics such as vec_splat, vec_extract, and
vec_insert. By default, these match array element order corresponding to the
endianness for the target.
Should this documentation be clarified? As I ponder the problem, it is not
clear to me whether I should be fixing the load and store operations, or fixing
the layout of the "initialization vectors" in memory.
Suppose I have code such as the following:
static vector int v = { 0, 1, 2, 3 };
int *ip = (int *)
fprintf (stderr, "The vector contains { %d, %d, %d, %d }\n",
ip[0], ip[1], ip[2], ip[3]);
Do I expect different output depending on whether this program is compiled with
-maltivec=be?
My first inclination is to do "extra swapping" (or undo existing swapping) on
each load and store if the "Altivec element ordering" is different than the
target's default ordering. It's not entirely clear if this is what was
intended.
[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78303
--- Comment #1 from Michael Meissner ---
The problem is the tests use initialization (both static and auto
initialization). Unfortunately, when initializing a vector, the -maltivec=be
option is not checked when laying out the structure in memory.
Consider the following case:
vector int va = { 100, 200, 300, 400 };
This is laid out in memory for big endian, normal little endian, and little
endian with BE semantics as:
.long 100
.long 200
.long 300
.long 400
Because the vector is byte swapped when loaded on a LE system, and then the
index is swapped for normal -maltivec=LE but not for -maltivec=BE, vec_extract
will deliver the wrong element for vectors that are initialized.
