search for: 4x32bit

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 a...

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: llvm...

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

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