[LLVMdev] Vectors in structures

[Bob Wilson]

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).