On 28 September 2010 18:20, Bob Wilson <bob.wilson at apple.com> wrote:> Yes, there are multiple issues but they all involve source compatibility.Hi Bob, than this is a completely different matter altogether.> I do not have access to ARM's compiler(s) but I'm assuming that the first example will not compile because vadd_u32 expects arguments of type uint32x2_t. Using structs in llvm does not "fix" a compatibility problem, but it helps our users write NEON code that will work with ARM's compiler.Indeed, the types are different, you will get an incompatible parameter error.> I am getting requests that we do that regardless of ARM's opinion, but I've resisted based on the notion that portability and compatibility are worth fighting for. It is pretty ironic and frustrating to me to hear that even people at ARM think these wrapper structs are a bad idea. I would still prefer to have ARM publish specifications and guidelines that make it possible to write portable NEON code. Do you guys even care about that?Nobody said that the structures are a bad idea, nor that it's not worth fighting for compatibility. What I said was: 1. The use of structures is an implementation choice. GCC chooses not to, we chose to. Simple as that. 2. The use of structures, *in IR*, is not necessary. Even using structure in the source code, you can easily detect NEON types and transform the IR accordingly. We do concern ourselves with compatibility, more than people normally believe. But there are certain constraints (partners, design issues, integration) that we simply cannot ignore. My first proposition of making every NEON call an intrinsic could help not only IR generation and codegen, but also make the arm_neon.h header more compatible with ARM's without the need of reinterpreting structures. I still have to think more about it (haven't thought about the header at all, so far), but this is something I can do and am willing to do to help Clang without breaking compatibility with ARM (the last thing I would want). We could (maybe should) discuss the intrinsic issue off-list, though. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
On Sep 28, 2010, at 11:20 AM, Renato Golin wrote:> Nobody said that the structures are a bad idea, nor that it's not > worth fighting for compatibility. > > What I said was: > > 1. The use of structures is an implementation choice. GCC chooses not > to, we chose to. Simple as that.Really? ARM's specifications of these types show them as structs, and as my example demonstrates, GCC's "implementation choice" allows code that is incompatible with ARM's compiler. I guess you are saying that is OK.> 2. The use of structures, *in IR*, is not necessary. Even using > structure in the source code, you can easily detect NEON types and > transform the IR accordingly.I agree. I mentioned earlier that, as an implementation choice, llvm relies on its SROA optimization to remove the structs from the IR. You may choose to do that in the front-end. It shouldn't matter.> We do concern ourselves with compatibility, more than people normally > believe. But there are certain constraints (partners, design issues, > integration) that we simply cannot ignore.I really don't know what you mean here. It sounds like those "certain constraints" might be referring to the fact that GCC's implementation is widespread and has become a de facto standard. If that's the case it is silly for llvm to continue trying to enforce the stricter type checking required for compatibility with ARM's compiler. We'll just adopt GCC's approach. We've already had to support GCC-compatibility as an option, so dropping compatibility with ARM will make things easier for us. I'm just going to plan to go ahead with that. I would have preferred some official specification from ARM acknowledging GCC's approach as a valid alternative, but your statement (1) above seems to say exactly that.> My first proposition of making every NEON call an intrinsic could help > not only IR generation and codegen, but also make the arm_neon.h > header more compatible with ARM's without the need of reinterpreting > structures. I still have to think more about it (haven't thought about > the header at all, so far), but this is something I can do and am > willing to do to help Clang without breaking compatibility with ARM > (the last thing I would want). > > We could (maybe should) discuss the intrinsic issue off-list, though.Adding unnecessary intrinsics goes against the design philosophy of llvm and causes issues in the backend. I don't understand why that matters to you. If you have specific patches to propose for Clang, perhaps I can give you more specific feedback.
On 28 September 2010 19:54, Bob Wilson <bob.wilson at apple.com> wrote:> Really? ARM's specifications of these types show them as structs, and as my example demonstrates, GCC's "implementation choice" allows code that is incompatible with ARM's compiler. I guess you are saying that is OK.OK in the sense that it works, yes. OK in the sense that I welcome it, then no. I'm not an old ARM employee, so I don't know all the decisions taken on NEON specs or why GCC had the design decisions it had. But I can't possibly believe that they have to do what ARM says they should. What I can do, however, is to help you keep the source compatibility and reduce the cost of producing IR, if you think it's worth the cost. I never said it wasn't, and you seem to think it is, so I guess we agree in that.> We've already had to support GCC-compatibility as an option, so dropping compatibility with ARM will make things easier for us. I'm just going to plan to go ahead with that. I would have preferred some official specification from ARM acknowledging GCC's approach as a valid alternative, but your statement (1) above seems to say exactly that.You're taking conclusions on your own thoughts... please don't put words in my mouth. The only point I made in my first email is that using structures in the IR was not necessary, regardless of the headers. If you want to keep source compatibility with armcc, I welcome and can help you. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm