[LLVMdev] Vectors in structures

[Alasdair Grant]

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

I was lead on the NEON intrinsics in the ARM compiler back in 2005,
but I didn't do the gcc implementation, or write that bit of the ABI.

We wanted to define types and intrinsics, with readable names (not too
many underscores) but without polluting the user namespace (in the C sense).
So we had arm_neon.h define the user-level types and intrinsics in terms of
types (__simdxx) and intrinsics (__ndp_xxx) in the C implementation namespace.
The __simd types are "intrinsic" types - i.e. types that are recognized
and handled specially by the front end.  They're structures because that
was the easiest way to create a specially-named type with a certain size
and alignment, as we didn't have anything like gcc's vector_size attribute.
We didn't intend programmers would be able to do anything with the __simd
structures, and our own compiler documentation (as opposed to our ABI
specification) doesn't even mention them.

The name mangling is a consequence of our implementation - in our compiler
the mangling happens to be done at a point in the front end where the types
have the __simd names and before they get lowered to native vectors.
With hindsight, we should have defined a specific name mangling rule.

Several years later, the NEON intrinsics were implemented in gcc.
At that point we had two implementations of the intrinsics, and it was
thought they should work together at the binary level too.  So at least
the parameter passing and mangling had to be defined.  Appendix A was
added to the AAPCS.  Essentially it reverse-engineers enough of the
original implementation so that if you implement it the same way (i.e.
using struct __simdxxx), the parameter passing and name mangling would
fall out naturally.  But as we know from gcc, you can make the types
whatever you want as long as you arrange for the parameter passing and
mangling to follow the rules.  So the ABI requires more than is needed
for binary compatibility (and more than gcc in fact does) and not enough
for source compatibility.

We're having some discussions here about how we can reword the ABI to
make it clearer what is required of an implementation.

In any case, anything we say about source compatibility or binary
compatibility shouldn't constrain how a compiler works internally.
Though with LLVM bitcode being in some sense an 'interface', there might
be benefit in agreeing how particular kinds of things (e.g. architecture
or language-specific features) were represented in LLVM-IR.  I.e. a
specialization or binding of LLVM-IR for an architecture.

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.