From: Janis Johnson <janis187@us.ibm.com>
To: gcc@gcc.gnu.org
Cc: lorenz@us.ibm.com
Subject: generic vectors: how should they work?
Date: Wed, 01 Sep 2004 00:35:00 -0000 [thread overview]
Message-ID: <20040901003511.GA8377@us.ibm.com> (raw)
GCC's generic vector extension is not clearly specified. I've been
playing around to find out how this stuff works now and asking lots of
questions of Paolo Bonzini, who currently knows the most about the
extension. Here's my summary of how things seem to work, which parts
need fixing, and some of the biggest holes. My goal is to get the right
people (whoever you might be) to help tighten the specification and fill
the holes.
Christine Lorenz is planning to rewrite the section of the GCC Manual
that describes this extension, so I've copied her. She's on vacation
this week.
I'll be taking off for four weeks starting September 4. If anyone is
inspired to take over figuring out how this stuff is supposed to work,
feel free; otherwise I'll pick it up when I return.
I don't have strong feelings about how generic vectors ought to work, or
even whether they should be supported at all. Any extension ought to be
documented and tested; otherwise we'll confuse users who stumble upon
them, think they look useful, and then complain when the features don't
work as expected.
Janis
why use generic vectors?
allow portable code to use hardware vector support on multiple
architectures (is this significantly different from using arrays in
simple loops that can be vectorized?)
declaration of vector variable
base types: float, double, any integral scalar type
const, volatile qualifiers can appear anywhere
__attribute__((vector_size(N))) can appear anywhere
vector size is the number of bytes in the vector, must be power of two
limit on vector size is 256 elements (bug: currently there's an ICE,
no error message from the front end)
operators
binary arithmetic operators: +, -, *, /
unary arithmetic operator: -
binary bitwise operators: ^,|, &
unary bitwise operator: ~
(bug: currently these don't work from C++)
operations are performed on corresponding elements of the operands
with the result stored in the corresponding element of the result
limitations on types of operands are not well-specified
requirements for casts are not well-specified
casts
currently merely does bit copy from one vector object to another
(what's the point?)
cast that would coerce values when used on scalars should either
coerce values on an element-by-element basis (like operators) or
should be an error (bug: currently it merely does a bitwise copy
between integer and floating point types)
limit use of cast to vectors of the same size and/or vectors with
the same number of elements?
assignment
should assignment coerce values or merely move bits? (same issue
as for cast)
alignment
ABI issue; does this depend on whether a vector type has hardware
support? (should always be aligned on processor families that support
vectors, even if the specific target doesn't, for interoperability)
arguments and function results
depends on ABI, which might specify that they are handled differently
depending on whether a vector is a hardware vector (ABIs don't yet
cover this)
passing pointers by value might not be interoperable between modules
compiled with and without hardware vector support; more portable to
pass vectors via pointers
mapping to hw vectors, optimizations, tuning
a vector whose type is supported by the target hardware is treated the
same as if it had been defined using the target's builtin __vector
keyword
a vector that is larger than what the target hardware supports and
whose base type is supported by hardware vectors is constructed from
multiple hardware vectors; what this mean depends on the ABI (although
ABIs don't currently cover this)
anything else is handled by software (bug: vectors smaller than what's
supported by hardware try to use hw vectors on powerpc64-linux)
in practice, vectors with 16 or more elements are inefficient
implementation details should be covered in the GCC Internals Manual
next reply other threads:[~2004-09-01 0:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-01 0:35 Janis Johnson [this message]
2004-09-01 2:11 ` David Edelsohn
2004-09-01 7:11 ` Paolo Bonzini
2004-09-01 14:49 ` David Edelsohn
2004-09-01 15:13 ` Paolo Bonzini
2004-09-01 15:35 ` Giovanni Bajo
2004-09-01 16:00 ` Paolo Bonzini
2004-09-01 19:52 ` Richard Henderson
2004-09-01 22:08 ` David Edelsohn
2004-09-02 13:04 ` Paolo Bonzini
2004-09-02 14:06 ` David Edelsohn
2004-09-02 14:27 ` Paolo Bonzini
2004-09-02 18:33 ` Janis Johnson
2004-09-01 23:47 ` Janis Johnson
2004-09-02 17:46 ` Janis Johnson
2004-09-01 20:12 ` James E Wilson
2004-09-01 20:40 ` David Edelsohn
2004-09-01 21:22 ` James E Wilson
2004-09-02 1:07 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040901003511.GA8377@us.ibm.com \
--to=janis187@us.ibm.com \
--cc=gcc@gcc.gnu.org \
--cc=lorenz@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).