On 27 September 2010 23:03, Bob Wilson <bob.wilson at apple.com> wrote:> Can you clarify ARM's position on those structure types? It sounds like you are advocating that we get rid of them. The only reason we've been using them in llvm-gcc and clang is for compatibility for ARM's specifications and with ARM's RVCT compiler. If ARM does not care about those things, I'd love to remove the struct wrappers from llvm.As Al said earlier, you definitely don't need the structures for compatibility with armcc. As far as the LLVM back-end is concerned, with or without structures, the instruction selection works a treat and generates correct NEON instructions. If the final object has the correct instructions and follows ARM ABIs, there is no point in keeping IR compatibility. I also noticed that Clang's arm_neon.h is completely different from armcc's, another non-compatible choice that has no impact in the final object code generated. As far as I can see, there is no gain in adding the wrapping structures to the vector types. I'll add the intrinsic to the VCEQ.P8 locally and test. If that works, I'll be sending patches to NEON.td for all ambiguities I find... -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
On Sep 27, 2010, at 3:23 PM, Renato Golin wrote:> On 27 September 2010 23:03, Bob Wilson <bob.wilson at apple.com> wrote: >> Can you clarify ARM's position on those structure types? It sounds like you are advocating that we get rid of them. The only reason we've been using them in llvm-gcc and clang is for compatibility for ARM's specifications and with ARM's RVCT compiler. If ARM does not care about those things, I'd love to remove the struct wrappers from llvm. > > As Al said earlier, you definitely don't need the structures for > compatibility with armcc.An implementation, such as in GCC, that does not use structures is compatible with ARM's specification in only one direction. GCC will accept any code written for RVCT, but not the other way around. And, as Al pointed out, there are also compatibility issues with how you can initialize vectors. (In fact, if you stick to the documented interfaces, the only way you can initialize a vector to an arbitrary value is by loading from memory.) Can we get an official position from ARM on this?> > As far as the LLVM back-end is concerned, with or without structures, > the instruction selection works a treat and generates correct NEON > instructions. If the final object has the correct instructions and > follows ARM ABIs, there is no point in keeping IR compatibility.We care about llvm IR compatibility across releases, but we can auto-upgrade old bitcode files to work with newer releases of llvm. I don't think this is relevant to the question of structs vs. no-structs.> > I also noticed that Clang's arm_neon.h is completely different from > armcc's, another non-compatible choice that has no impact in the final > object code generated.Each compiler can have its own version of arm_neon.h. llvm-gcc's is quite different from clang. That is an internal implementation issue.> > As far as I can see, there is no gain in adding the wrapping > structures to the vector types. > > I'll add the intrinsic to the VCEQ.P8 locally and test. If that works, > I'll be sending patches to NEON.td for all ambiguities I find...Wait a minute.... VCEQ does not have a special polynomial version. There is only VCEQ.I8. What I said about support for polynomial types in Clang is still true, but for this particular case, there is no difference between vceq_s8, vceq_u8, and vceq_p8 (aside from the types of the intrinsic arguments).
On 27 September 2010 23:45, Bob Wilson <bob.wilson at apple.com> wrote:> An implementation, such as in GCC, that does not use structures is compatible with ARM's specification in only one direction. GCC will accept any code written for RVCT, but not the other way around. And, as Al pointed out, there are also compatibility issues with how you can initialize vectors. (In fact, if you stick to the documented interfaces, the only way you can initialize a vector to an arbitrary value is by loading from memory.)Hi Bob, Can you clarify what compatibility problems you had with GCC? And that by using structures in Clang you made it work with armcc? Is it just a source code compatibility issue?> Can we get an official position from ARM on this?I really don't know what you want here. I can't tell you that it will be safe to remove the structures from Clang, since I don't know enough about the vector types (and all other back-ends that use it) and what the problems you had with gcc/armcc compatibility. Maybe, because of the way vectors are implemented in LLVM, there is no other way... maybe not.> Wait a minute.... VCEQ does not have a special polynomial version. There is only VCEQ.I8. What I said about support for polynomial types in Clang is still true, but for this particular case, there is no difference between vceq_s8, vceq_u8, and vceq_p8 (aside from the types of the intrinsic arguments).Sorry, bad example... (and wrong copy&past test generation) ;) -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm