[IR] Add LLVM IR support for aarch64_svcount opaque type.

[sdesmalen]

Summary

The C and C++ Language Extensions for AArch64 SME2 [1] adds a new type called
svcount_t which describes a predicate. This is not a predicate vector
mask, but rather a description of a predicate vector mask that can be
expanded into a mask using explicit instructions. The type is a scalable
opaque type.

To implement svcount_t type this patch adds an opaque LLVM IR type as well as
support for parsing, assembling and a LangRef description. AArch64 CodeGen
support will follow in a separate patch.

[1] https://github.com/ARM-software/acle/pull/217

Patch co-authored by @CarolineConcatto

[nikic]

Any chance this can be implemented as an opaque type as introduced in https://reviews.llvm.org/D135202 instead? Providing a general mechanism for target-specific types is the purpose of opaque types, so it would be great if they work for this use case. cc @jcranmer-intel

[aemerson]

In D136861#3889474, @nikic wrote:

Any chance this can be implemented as an opaque type as introduced in https://reviews.llvm.org/D135202 instead? Providing a general mechanism for target-specific types is the purpose of opaque types, so it would be great if they work for this use case. cc @jcranmer-intel

Can this be implemented in the existing way? Otherwise users of -DCLANG_ENABLE_OPAQUE_POINTERS=OFF/-Xclang -no-opaque-pointers won't be able to use SME intrinsics.

[nikic]

In D136861#3889897, @aemerson wrote:

In D136861#3889474, @nikic wrote:

Any chance this can be implemented as an opaque type as introduced in https://reviews.llvm.org/D135202 instead? Providing a general mechanism for target-specific types is the purpose of opaque types, so it would be great if they work for this use case. cc @jcranmer-intel

Can this be implemented in the existing way? Otherwise users of -DCLANG_ENABLE_OPAQUE_POINTERS=OFF/-Xclang -no-opaque-pointers won't be able to use SME intrinsics.

Despite both having "opaque" in the name, opaque pointers and opaque types aren't really related. Opaque types would work even with -no-opaque-pointers.

[aemerson]

In D136861#3889901, @nikic wrote:

In D136861#3889897, @aemerson wrote:

In D136861#3889474, @nikic wrote:

Any chance this can be implemented as an opaque type as introduced in https://reviews.llvm.org/D135202 instead? Providing a general mechanism for target-specific types is the purpose of opaque types, so it would be great if they work for this use case. cc @jcranmer-intel

Can this be implemented in the existing way? Otherwise users of -DCLANG_ENABLE_OPAQUE_POINTERS=OFF/-Xclang -no-opaque-pointers won't be able to use SME intrinsics.

Despite both having "opaque" in the name, opaque pointers and opaque types aren't really related. Opaque types would work even with -no-opaque-pointers.

Ah ok, that's fine then. Although from looking at D135202 it doesn't look like the design has been settled yet? I don't think we should be writing patches upon speculative changes, so unless D135202 is going to land very soon I'd prefer we continued with the traditional approach.

[nikic]

In D136861#3890025, @aemerson wrote:

Ah ok, that's fine then. Although from looking at D135202 it doesn't look like the design has been settled yet? I don't think we should be writing patches upon speculative changes, so unless D135202 is going to land very soon I'd prefer we continued with the traditional approach.

Yeah, possibly. I'd suggest to still consider the possibility when you put up the RFC for this change, as it's likely going to be an easier sell if it doesn't require the addition of a new target-specific type.

[jcranmer-intel]

In D136861#3890025, @aemerson wrote:

Ah ok, that's fine then. Although from looking at D135202 it doesn't look like the design has been settled yet? I don't think we should be writing patches upon speculative changes, so unless D135202 is going to land very soon I'd prefer we continued with the traditional approach.

At a quick glance of this patch, this does seem like something that could be built on top of opaque types were they already landed, so it's at least worth considering how this type might be implemented as an opaque type. The thing that's the most unsettled in the design is effectively the communication of DataLayout-like type properties of target types, and while I hoped to have a solution to that coded up today, I didn't get enough time to do so.

[efriedma]

From the spec, svreinterpret_c(svreinterpret_b(x)) is equivalent to x, right? So you could just lower svcount_t to <vscale x 16 x i1>, but you want to avoid confusion with non-SME predicate vectors in LLVM IR?