[LLVMdev] Vectors in structures

[Bob Wilson]

On Sep 21, 2010, at 9:33 AM, Renato Golin wrote:

> Second question:
> 
> I was checking NEON instructions this week and the vector types seem
> to be inside structures. If vector types are considered proper types
> in LLVM, why pack them inside structures?

Because that is what ARM has specified?  They define the vector types that are used with their NEON intrinsics as "containerized vectors".  Perhaps someone on the list from ARM can explain why they did it that way.

The extra structures are irrelevant at the llvm IR level and below.  The NEON intrinsics in llvm use plain old vector types.

If you're using llvm-gcc, you can define the ARM_NEON_GCC_COMPATIBILITY preprocessor macro, and it will switch to a version of the NEON intrinsics that use plain vector types instead of the containerized vectors.  For clang, we are planning to do something similar (without requiring the macro) by overloading the intrinsic functions to take either type of arguments, but that is not yet implemented.

> 
> That results in a lot of boilerplate code for converting and copying
> the values (about 20 lines of IR) just to call a NEON instruction
> that, in the end, will be converted into three instructions:
> 
> VLDR + {whatever} + VSTR
> 
> If the load and store are normally performed by one operation (I
> assume it's the same on Intel and others), why bother with the
> structure passing instead of just using load/store for vector types?

As you noted, the struct wrappers produce a lot of extra code but it should all be optimized away.  If you see a case where that is not happening, please file a bug report.

> 
> Also, the extra struct { [i8 x 8] } for memcopy seems also redundant.
> If you're explicitly telling you want NEON (or whatever vector
> instructions), why bother with compatibility?

I don't know what you're referring to here.  Can you give an example?