Bug 57547 - Missing vector intrinsics in PowerPC Altivec documentation
Summary: Missing vector intrinsics in PowerPC Altivec documentation
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.8.1
: P3 trivial
Target Milestone: ---
Assignee: Bill Schmidt
URL:
Keywords: documentation
Depends on:
Blocks:
 
Reported: 2013-06-06 20:06 UTC by Wainer dos Santos Moschetta
Modified: 2021-04-16 15:42 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-06-06 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wainer dos Santos Moschetta 2013-06-06 20:06:19 UTC
It is missing following vector intrinsics in the PowerPC Altivec documentation:
vec_extract
vec_insert
vec_promote
vec_recipdiv

The PowerPC Altivec online documentation
http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/PowerPC-AltiVec_002fVSX-Built_002din-Functions.html#PowerPC-AltiVec_002fVSX-Built_002din-Functions
Comment 1 Andrew Pinski 2013-06-06 20:08:09 UTC
I think the vec_extract/vec_insert/vec_promote are my fault as I added them for Cell.
Comment 2 kelvin 2018-02-06 16:38:00 UTC
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 *) &v;
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.
Comment 3 kelvin 2018-02-06 16:40:17 UTC
Oops.  Sent that comment to the wrong bugzilla.  Please disregard.
Comment 4 Bill Schmidt 2021-04-16 15:42:10 UTC
Documentation updated today to point to the master vector intrinsic reference.