[LLVMdev] Vectors in structures

[Renato Golin]

On 28 September 2010 18:20, Bob Wilson <bob.wilson at apple.com> wrote:
> Yes, there are multiple issues but they all involve source compatibility.

Hi Bob, than this is a completely different matter altogether.


> I do not have access to ARM's compiler(s) but I'm assuming that the first example will not compile because vadd_u32 expects arguments of type uint32x2_t.  Using structs in llvm does not "fix" a compatibility problem, but it helps our users write NEON code that will work with ARM's compiler.

Indeed, the types are different, you will get an incompatible parameter error.


> I am getting requests that we do that regardless of ARM's opinion, but I've resisted based on the notion that portability and compatibility are worth fighting for.  It is pretty ironic and frustrating to me to hear that even people at ARM think these wrapper structs are a bad idea. I would still prefer to have ARM publish specifications and guidelines that make it possible to write portable NEON code.  Do you guys even care about that?

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.

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.

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.

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.

-- 
cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm