search for: intnxn_t

...types), as per the discussion we're having about needing to use structures. Make that 2x smaller, I had a special case that was not a fair comparison. But I recently found out that the polyNxN_t vector type can destroy everything, as it appears to LLVM as <8 x i8>, 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.__sim...

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

...we're having about needing to use > structures. Make that 2x smaller, I had a special case that was not a > fair comparison. > > But I recently found out that the polyNxN_t vector type can destroy > everything, as it appears to LLVM as <8 x i8>, 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_i...

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