[LLVMdev] LLVMdev Digest, Vol 80, Issue 13

[Villmow, Micah]

Andrew,
 This is one area of LLVM that maps very nicely to our GPU architecture. A vector is a native data type on these architectures. For example, on AMD's GPUs, the native type is 4x32bit vector with sub-components. Each of the individual 32bits can be indexed separately, but not dynamically. This is a big difference from an array of 32bit values. So there are cases where the meaning of the two are different on modern hardware.

Micah

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Andrew Clinton
> Sent: Monday, February 14, 2011 1:14 PM
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] LLVMdev Digest, Vol 80, Issue 13
> 
> Agreed, I too was wondering why we need both arrays and vectors.  It
> goes against the grain, I think, of the structure typing system used by
> LLVM.  For example, a vector of 4 floats and an array of 4 floats are
> structurally the same type.  Would it be feasible in the future to
> consolidate the two types by allowing "vector" operations (add,
> multiply, etc.) on arrays where it makes sense, and doing away with the
> specialized vector types?
> 
> Andrew
> 
> On 02/14/2011 03:49 PM, Peter Lawrence wrote:
> > Andrew,
> >                  your response highlights a naming problem in LLVM,
> > which is that  "array" and "vector"
> > mean the same thing in normal computer language and compiler theory
> > usage, so it is
> > inconvenient and misleading within LLVM to give one a very specific
> > meaning that is different
> > from the other....
> >
> > to the LLVM developers I would suggest using the term "packed" to
> > refer to the type of
> > data that the SPARC-VIS, the PPC-Altivec, and the Intel-mmx/sse
> > (among others) instruction
> > sets support.
> >
> > As far as I am aware not a single one of any of the above types of
> > instruction sets allows the "subscripting" of packed data within a
> > register  (the Maspar
> > computer had hardware that would allow subscripting of sub-elements
> > of data within
> > a larger/wider register, but it was the exception, not the rule, and
> > it did not support
> > any of the saturating arithmetic that is part-and-parcel of the
> > packed data types in
> > the currently existing "multi-media instruction sets").
> >
> >
> > sincerely,
> > Peter Lawrence.
> >
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev