search for: __simd64_int8_t

...and is identical to a intNxN_t for base instructions, so an "icmp eq <8 x i8>" always become VCEQ.I8 and never a VCEQ.P8, even though that's what Clang generates. Putting them into structures doesn't help because of the type names being irrelevant, both names become %struct.__simd64_int8_t %struct.__simd64_int8_t = type { <8 x i8> } %struct.__simd64_poly8_t = type { <8 x i8> } %struct.__simd64_uint8_t = type { <8 x i8> } @u8d = common global %struct.__simd64_int8_t zeroinitializer, align 8 @i8d = common global %struct.__simd64_int8_t zeroinitializer, align 8 @p8d...

On Sep 27, 2010, at 2:58 AM, Renato Golin wrote: > On 22 September 2010 03:43, Bob Wilson <bob.wilson at apple.com> wrote: >> But regardless they are still structures, right? What does it mean for them to map onto other types? Is the parser supposed to treat them as if they _were_ those other types? If so, I think you need to define a type system for those fundamental vector

...; intNxN_t for base instructions, so an "icmp eq <8 x i8>" always become > VCEQ.I8 and never a VCEQ.P8, even though that's what Clang generates. > > Putting them into structures doesn't help because of the type names > being irrelevant, both names become %struct.__simd64_int8_t > > %struct.__simd64_int8_t = type { <8 x i8> } > %struct.__simd64_poly8_t = type { <8 x i8> } > %struct.__simd64_uint8_t = type { <8 x i8> } > > @u8d = common global %struct.__simd64_int8_t zeroinitializer, align 8 > @i8d = common global %struct.__simd64_in...

On 22 September 2010 03:43, Bob Wilson <bob.wilson at apple.com> wrote: > But regardless they are still structures, right?  What does it mean for them to map onto other types?  Is the parser supposed to treat them as if they _were_ those other types?  If so, I think you need to define a type system for those fundamental vector types.  I had read those statements to say something about the

...describe the short vector types" which I guess could be read as saying they are packed inside structures - but I don't think this is the intention and it doesn't match implementations. The arm_neon.h implementation in the ARM compiler defines the user types in terms of C structs called __simd64_int8_t etc. and the mangling originated as an artifact of this. But the C structs aren't wrapped vectors; they wrap double or a pair of doubles, to get the size and alignment. Their only purpose is to be recognized by name by the front end and turned into a native register type. In gcc's arm_neo...

...ector types" which I guess could be read > as saying they are packed inside structures - but I don't think this > is the intention and it doesn't match implementations. > The arm_neon.h implementation in the ARM compiler defines the user > types in terms of C structs called __simd64_int8_t etc. and the > mangling originated as an artifact of this.  But the C structs aren't > wrapped vectors; they wrap double or a pair of doubles, to get the > size and alignment.  Their only purpose is to be recognized by name > by the front end and turned into a native register type....

On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: > Second question: > > I was checking NEON instructions this week and the vector types seem > to be inside structures. If vector types are considered proper types > in LLVM, why pack them inside structures? Because that is what ARM has specified? They define the vector types that are used with their NEON intrinsics as

Second question: I was checking NEON instructions this week and the vector types seem to be inside structures. If vector types are considered proper types in LLVM, why pack them inside structures? That results in a lot of boilerplate code for converting and copying the values (about 20 lines of IR) just to call a NEON instruction that, in the end, will be converted into three instructions: VLDR

...; which I guess could be read >> as saying they are packed inside structures - but I don't think this >> is the intention and it doesn't match implementations. >> The arm_neon.h implementation in the ARM compiler defines the user >> types in terms of C structs called __simd64_int8_t etc. and the >> mangling originated as an artifact of this. But the C structs aren't >> wrapped vectors; they wrap double or a pair of doubles, to get the >> size and alignment. Their only purpose is to be recognized by name >> by the front end and turned into a native...