[clang] [CLANG][AArch64]Add Neon vectors for mfloat8_t (PR #99865)

[Momchil Velikov via cfe-commits]

================
@@ -97,6 +97,17 @@
   SVE_TYPE(Name, Id, SingletonId)
 #endif
 
+#ifndef AARCH64_VECTOR_TYPE
----------------
momchil-velikov wrote:

This naming seems odd to me. So, far we've got a sort of taxonomy, or "isA" relationship
that looks like:

    SVE_VECTOR_TYPE_BFLOAT -> SVE_VECTOR_TYPE_DETAILS -> SVE_VECTOR_TYPE -> SVE_TYPE
                              ^  ^                                           ^  ^
                              |  |                                           |  |
    SVE_VECTOR_TYPE_FLOAT ----+  |                                           |  |
    SVE_VECTOR_TYPE_INT ---------+                                           |  |
    SVE_PREDICATE_TYPE_ALL  ---------------------------> SVE_PREDICATE_TYPE -+  |  
                                                         SVE_OPAQUE_TYPE -------+

And now appears

    AARCH64_VECTOR_TYPE -> SVE_TYPE

where the relation implied by the naming goes in the opposite direction.

It would look more sensible to have

    SVE_VECTOR_TYPE_BFLOAT -> SVE_VECTOR_TYPE_DETAILS -> SVE_VECTOR_TYPE -> SVE_TYPE --> AARCH64_VECTOR_TYPE --> AARCH64_TYPE
                              ^  ^  ^                                        ^  ^        ^
                              |  |  |                                        |  |        |
    SVE_VECTOR_TYPE_FLOAT ----+  |  |                                        |  |        |
    SVE_VECTOR_TYPE_INT ---------+  |                                        |  |        |
    SVE_VECTOR_TYPE_MFLOAT ---------+                                        |  |        |
    SVE_PREDICATE_TYPE_ALL  ---------------------------> SVE_PREDICATE_TYPE -+  |        |
                                                         SVE_OPAQUE_TYPE -------+        |
    SIMD_VECTOR_TYPE_MFLOAT  --------------------------> SIMD_VECTOR_TYPE ---------------+

(potentially collapsing "empty" classes, but still having them there conceptually)

and them having the implementation fit into a logical structure as the one above.
Admittedly, that'd cause some churn in the source.

https://github.com/llvm/llvm-project/pull/99865