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
I'm just suggesting that from the perspective of the LLVM IR there doesn't seem to be a necessary semantic difference between arrays and vectors. Arrays provide a superset of the functionality available for vectors. I would be happy if the code generator used 4x32bit vectors for basic math on [4xfloat] arrays, and fell back to something less efficient if the user decided to dynamically index it. However, maybe this is more work for the code generator than is currently feasible. On 02/14/2011 06:44 PM, Villmow, Micah wrote:> 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 >
On Feb 14, 2011, at 4:32 PM, Andrew Clinton wrote:> I'm just suggesting that from the perspective of the LLVM IR there > doesn't seem to be a necessary semantic difference between arrays and > vectors. Arrays provide a superset of the functionality available for > vectors. I would be happy if the code generator used 4x32bit vectors > for basic math on [4xfloat] arrays, and fell back to something less > efficient if the user decided to dynamically index it. However, maybe > this is more work for the code generator than is currently feasible.You could make the same argument for arrays and structs: {i32,i32,i32,i32} is (almost) semantically equivalent to [4 x i32]. Similarly, pointers and integers are semantically very similar. You could even say that an i32 and f32 should be the same type and just have different operations available on them. This would map naturally to SSE for example. The answer here is that having these differentiated in the type system makes analysis, optimization, and code generation easier. Having explicit vector types is definitely goodness. -Chris> > On 02/14/2011 06:44 PM, Villmow, Micah wrote: >> 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 >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev