search for: polynxn_t

...structure boilerplate and it still works, plus you don't have to define any type (as LLVM uses the vector 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'...

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

...till > works, plus you don't have to define any type (as LLVM uses the vector > 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...

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