Arm NEON vector types

[dkolsen-pgi]

Implement Arm NEON vector types in ClangIR.

Issue #284 implemented GNU vector types. Other issues are being created for other kinds of vector types. See https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors

[bcardosolopes]

I stumble into some neon builtins we need to build, and it's possible I might need to work on this soon. @dkolsen-pgi let me know if you have any plans to work on this - just wanna make sure we're don't duplicate work.

[dkolsen-pgi]

I don't have any immediate plans to work on this issue. It was a possible near-term issue, but those plans can easily change. In general, I will assign an issue to myself if I am planning to do any significant work.

[bcardosolopes]

I actually don't yet need anything other than plain fixed vectors for the things I need to support right now, so making this available again in case anyone needs it first then we do.

[bcardosolopes]

Actually, seems like the specific bits are already supported, the extensions probably gets unified, see https://godbolt.org/z/coGr5xh9K

@dkolsen-pgi am I missing something or should we just close this?

[bcardosolopes]

To be more specific: different vector types might restrict or change behavior of operations, but what I need to double check is whether this is already enforced by Sema (even though we might want to have extra verification at the CIR level).

[dkolsen-pgi]

I don't enough of the details about Arm NEON vector types to know if everything you can do with them is already covered by the existing CodeGen and Lowering support for GNU vector types. But I wouldn't be surprised if that was the case. There are different semantic rules for GNU vector types and Arm NEON vector types, but that's the responsibility of Clang's Sema to enforce that. But once code makes it past semantic checking, it's quite possible that the behavior is the same.

I wouldn't close this issue just yet. But put it on the back burner for now. If we implement Arm SVE vectors without finding any necessary NEON-specific changes, then we should close this one.

[bcardosolopes]

Sounds good.

Note for later: There are probably better links, but this doc on page 131 has a table that might be helpful. Even though Sema does most of the job, we could run into issues for transformations on top of CIR. Since fixed vectors are shared right now, it's possible vector transformations could generate code that isn't really supported by the type - we probably need an example to confirm. One possible solution is to add an attribute kind to vector type to distinguish between neon, etc, so that verifiers would catch subtle issues like that.