> They are defined as structures. The table in A.2 defines the exact > structure names. There is a requirement to mangle them as those > structures in A.2.1.The mangling requirement doesn't require you to meet it in any particular way as long as you end up with the right strings. I.e. the mangling requirement places no requirements at all on the implementation, outside of mangled names. The controversial statement is where A.2 requires the user types to map on to the __simd64 structures. But that still isn't an argument for wrapping. This sentence might be significant: "The structures have 64-bit alignment and map directly onto the containerized vector fundamental data types." So the structures map _directly_ on to the vector types - not on to wrappers around the vector types.> The fields of the structure may be different in > this implementation, but the net effect here is that llvm-gcc and > clang avoid having to magically recognize NEON types and substitute > the proper mangling for them the way GCC does.But mangling routines are self-contained and have to deal with this sort of target issue anyway, e.g. gcc for ARM deals with 16-bit floats as well as NEON types. Saving 20 or so lines in a mangling routine makes no sense as an argument for a particular implementation strategy for arm_neon.h and a front end, let alone for inflating bitcode files with lots of wrapping around vector operations. Al -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Sep 21, 2010, at 5:40 PM, Alasdair Grant wrote:>> They are defined as structures. The table in A.2 defines the exact >> structure names. There is a requirement to mangle them as those >> structures in A.2.1. > > The mangling requirement doesn't require you to meet it in any > particular way as long as you end up with the right strings. > I.e. the mangling requirement places no requirements at all on > the implementation, outside of mangled names. > > The controversial statement is where A.2 requires the user types to > map on to the __simd64 structures. But that still isn't an argument > for wrapping. This sentence might be significant: > > "The structures have 64-bit alignment and map directly onto the > containerized vector fundamental data types." > > So the structures map _directly_ on to the vector types - not on to > wrappers around the vector types.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 data types used in the generated code.> >> The fields of the structure may be different in >> this implementation, but the net effect here is that llvm-gcc and >> clang avoid having to magically recognize NEON types and substitute >> the proper mangling for them the way GCC does. > > But mangling routines are self-contained and have to deal with this > sort of target issue anyway, e.g. gcc for ARM deals with 16-bit > floats as well as NEON types. Saving 20 or so lines in a mangling > routine makes no sense as an argument for a particular implementation > strategy for arm_neon.h and a front end, let alone for inflating > bitcode files with lots of wrapping around vector operations.Agreed. The mangling is a side issue.> > Al > > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
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 data types used in the generated code.Hi Bob, Just tested with plain vectors and LLVM's back-end seems to get them all right. Plain instructions (add, mul, sub) and intrinsics (adds, subs, muls). Haven't seen any compatibility issues so far, not to mention that the IR is a fifth of what Clang generates... ;) -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm