[LLVMdev] Vectors in structures

[Bob Wilson]

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.