[LLVMdev] Vectors in structures

[Bob Wilson]

On Sep 21, 2010, at 6:32 PM, Alasdair Grant wrote:

> Bob Wilson writes:
>> Right.  The contents of the struct don't matter -- the spec is pretty
>> clear about that -- so llvm uses vector types instead of doubles, but
>> your spec definitely shows them being defined as structs.
> 
> It _says_ they are defined as structs - but it doesn't show them
> in use, i.e. it doesn't show how a user of the NEON intrinsics is
> supposed to be able to make any use of the fact that the types
> are defined as structs rather than some completely opaque type.
> All it does is explain why the mangling rule looks the way it does.

We can deal with the mangling rule in other ways if necessary.  I don't read the mangling rule as necessarily implying anything about the actual data types.

The fact remains that ARM's documentation defines these types as structs.  A user should NOT be able to take advantage of that -- the types are intentionally opaque.

> 
> And whatever the effect of them being structs on the NEON intrinsics
> programmer might be, it surely wouldn't prevent them being lowered
> to native types when the struct-ness no longer mattered.  And I'd
> have thought that would be in the front end.

Where that lowering is done is an implementation detail of the compiler, isn't it?

The big question is in regard to "whatever the effect of them being structs".  As I pointed out, if you follow ARM's approach of making them structs, that has big implications for what types you can use for intrinsic arguments.  Most of the vreinterpret intrinsics are only needed if you define the NEON types as structs.  If they are GCC-style vectors, you can omit most of the vreinterpret calls.

> 
>> Beyond that, if you want any sort of cross-compiler portability, you
>> don't want to write code for GCC's implementation.  GCC lets you freely
>> intermix vector types, or at least integer vector types, as long as
>> they have the same total size.
> 
> Yes, other problem cases might be
> 
>  int16x4_t x = { 1, 2, 3, 4 };        // gcc only?
> 
>  struct float4: float32x4_t { ... };  // armcc only?

Yes, definitely.  These are the sorts of things that caused us to define a GCC backward-compatibility option.

> 
> We ought to be more specific about the portable subset, and give
> more guidance on potential portability issues.  Probably that would
> start with a common specification for the NEON intrinsics, independent
> of any given ARM or GNU compiler release.

That would be great.  My experience has been that the using the struct types as defined by ARM is a big nuisance, so if you can find a way to relax your specification to allow other implementations, that would be most welcome.

> 
> Al
> 
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.