[Clang][AArch64] Add/implement ACLE keywords for SME.

[sdesmalen]

Summary

This patch adds all the language-level function keywords defined in:

https://github.com/ARM-software/acle/pull/188 (merged)
https://github.com/ARM-software/acle/pull/261 (update after D148700 landed)

The keywords are used to control PSTATE.ZA and PSTATE.SM, which are
respectively used for enabling the use of the ZA matrix array and Streaming
mode. This information needs to be available on call sites, since the use
of ZA or streaming mode may have to be enabled or disabled around the
call-site (depending on the IR attributes set on the caller and the
callee). For calls to functions from a function pointer, there is no IR
declaration available, so the IR attributes must be added explicitly to the
call-site.

With the exception of 'arm_locally_streaming' and 'arm_new_za' the
information is part of the function's interface, not just the function
definition, and thus needs to be propagated through the
FunctionProtoType::ExtProtoInfo.

This patch adds the defintions of these keywords, as well as codegen and
semantic analysis to ensure conversions between function pointers are valid
and that no conflicting keywords are set. For example, 'arm_streaming'
and 'arm_streaming_compatible' are mutually exclusive.

[sdesmalen]

• Removed attribute handling from SemaDeclAttr.cpp, so that the type attributes are only handled in SemaType.cpp
• Made ArmLocallyStreaming a DeclOrTypeAttribute again.
• Added new tests.

[sdesmalen]

Thanks for your patience reviewing this patch @aaron.ballman!

clang/include/clang/AST/Type.h

4064

This field is added to ExtProtoInfo struct, which is used to populate the ExtraBitfields in the FunctionPrototype's AST node.

Sorry if this wasn't clear because the diff had no context. arc diff wasn't working for me, so manually updated the patch, but then forgot to add full context.

clang/include/clang/Basic/Attr.td

2333

Okay, I've removed the handling in SemaDeclAttr, so that it is only handled in SemaType.cpp.

But it still allows the attribute to be applied to any position in the function declaration, i.e.

__attribute__((arm_streaming)) float foo1(int);
float __attribute__((arm_streaming)) foo2(int);
float foo3(int) __attribute__((arm_streaming));

Is that expected?

2345

You're right that it shouldn't be. I want it to just be a decl attribute and don't want it to be either a Type or a Stmt attribute, but that doesn't seem to exist.
I find their meaning quite confusing, because both allow me to limit their applicability to Functions. What is the right class to derive from here?

2435

If it's an attribute that applies to the type of the function, you should not be allowed to specify it on the declaration

Could you maybe give me an example here of what it looks like to apply the attribute to the function *type* when it's not allowed on the *declaration*? Does this all have to do with the position of the attribute in the declaration statement? When writing a function declaration it defines both the name and the type of that function, so there's no way to write a declaration without also defining its type.

Maybe it helps if you have any pointers that explain the difference in syntax between function declaration/function type attributes (https://clang.llvm.org/docs/AttributeReference.html doesn't really address this)

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

This error and the one below make me wonder whether an attribute spelling is the appropriate way to surface this functionality as opposed to a keyword.

I'm not sure I understand what you mean, do you have an example?

clang/test/Sema/aarch64-sme-func-attrs.c

214

Great suggestions, thanks! They both seem to be handled correctly.

[aaron.ballman]

In D127762#3615702, @sdesmalen wrote:

Thanks for your patience reviewing this patch @aaron.ballman!

Happy to help, thank you for your patience with my constant stream of questions about the design. :-)

clang/include/clang/AST/Type.h

4064

Ah, I see what's going on there, thank you (the extra context helped as well).

clang/include/clang/Basic/Attr.td

2333

https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax

"For compatibility with existing code written for compiler versions that did not implement attributes on nested declarators, some laxity is allowed in the placing of attributes. If an attribute that only applies to types is applied to a declaration, it is treated as applying to the type of that declaration. If an attribute that only applies to declarations is applied to the type of a declaration, it is treated as applying to that declaration; and, for compatibility with code placing the attributes immediately before the identifier declared, such an attribute applied to a function return type is treated as applying to the function type, and such an attribute applied to an array element type is treated as applying to the array type. If an attribute that only applies to function types is applied to a pointer-to-function type, it is treated as applying to the pointer target type; if such an attribute is applied to a function return type that is not a pointer-to-function type, it is treated as applying to the function type."

So yes, that's expected because the attribute only applies to types, so it magically "slides" onto the type regardless of where it was written on the declaration. By making it a type only attribute, it's now clear what the GNU attribute applies to regardless of where it's written.

2345

Hmm, we have some documentation at https://clang.llvm.org/docs/InternalsManual.html#how-to-add-an-attribute but it's not very clear on all the choices and when to pick which one.

For declaration attributes on a function, the question really boils down to whether you want redeclarations to automatically inherit the attribute or not. e.g.,

__attribute__((arm_locally_streaming)) void func(void);
void func(void); // Is this declaration also marked locally streaming?

void use(void) {
  func(); // Does this use see the attribute or not?
}

If you want the call in use() to see the attribute, then you want the attribute to be inherited on the redeclaration, and so you'd use InheritableAttr. If you don't want the call in use() to see the attribute, then you'd use Attr.

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

override and final could have been surfaced via attributes, and in Clang we semantically express them as such (see Final and Override in Attr.td), but instead they are surfaced to the user as keywords in the language standard. You're not under the same constraints as the standard (you're making a vendor-specific attribute). We're not super consistent with whether we use the same approach as the standard (we have some type attributes that are spelled as attributes like vector_size and others that are spelled via keywords like _Nullable.

So you could spell your type attributes the way you have been with __attribute__, or you could come up with keywords for them (so instead of using GNU<"whatever"> for the attribute, you could use Keyword<_Whatever> or Keyword<__whatever> (you'd also need to add them as recognized keyword tokens, parse them as appropriate, etc).

Note: I don't insist on you using a keyword for these, but I am wondering if that approach was considered or not given how non-portable the attributes are (if an implementation ignores this attribute, it sounds like the program semantics are unlikely to be correct).

clang/lib/Sema/SemaType.cpp

7913–7916

I'm sorry, I see now that I forgot to say the important bit that was in my head: we don't check those subjects automatically yet, but we do want to add more automation to type attribute processing as we've already done for declarations and statements, so we want the content in Attr.td to be as correct as possible even though it still needs to be manually checked. That makes it easier on us when we go to add the automation; there's less "which is correct, the SemaType.cpp code or the Attr.td declaration?" involved).

[sdesmalen]

• Rebased patch
• Use InheritableAttr for the ArmLocallyStreaming attribute instead of DeclOrTypeAttr
• Added test-case to test inheritable property of ArmLocallyStreaming
• Refactored enum as suggested

[sdesmalen]

The past few months we've worked to get the attributes at the LLVM IR side implemented. Since that work has now landed, this patch should no longer be held up by the LLVM side of things.

@aaron.ballman I've updated and rebased the patch. I went through all the comments again and believe that all of them have been addressed. Would you be happy to give this patch another look?

clang/include/clang/Basic/Attr.td

2345

Thanks for clarifying. I've changed the code to use InheritableAttr, since future redeclarations/redefinitions should inherit the arm_locally_streaming attribute (and also added an extra test-case for this)

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

@rsandifo-arm can you shed some light on whether using a keyword instead of an attribute was considered?

[rsandifo-arm]

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

Thanks @aaron.ballman for the reviews.

Yeah, we did consider using keywords instead. The main reason for sticking with GNU attributes is that they were specifically designed as an extensible way of attaching information or requirements to the source code, and they provide well-settled semantics. It seemed better to reuse an existing mechanism rather than invent something new.

Also, as C++ evolves, the semantics of GNU attributes evolve to match. If we surface the SME features as GNU attributes, we inherit this development in the underlying semantics, without having to maintain our own evolving specification for where the keywords can be placed. For example, when lambdas were introduced, GNU attributes were extended to support lambdas. Something similar could happen in future.

We could have defined the semantics of the keywords to be that they behave exactly like GNU attributes. However:

1. If we do that, the advantage of using a keyword is less obvious. (I can see the argument that the syntax looks nicer though.)
2. Like you say in the review, the semantics of GNU attributes carry some historical baggage. If would be difficult to justify keeping that historical baggage for something that is ostensibly new and not a GNU attribute as such.

A minor, but still nontrivial, reason is that there is less appetite in the GCC community for supporting target-specific extensions to the core language. Adding a target-specific keyword is likely to be rejected. It would be acceptable to make the “keyword” be a predefined macro that expands to a GNU attribute under the hood, but I don't think that would address the core issue.

I can definitely understand the unease about using attributes for things that affect semantics. Like you say, that's going against a core principle of the standard-defined attributes. But I think in a way, it's unfortunate that GNU-style attributes and standard-defined attributes are both called “attributes”, because I don't think there's a prohibition (even in theory) against GNU attributes affecting semantics. I think GNU attributes are designed to be more general than that, probably through historical accretion rather than an up-front choice.

Like you say, vector_size is one example of something that significantly affect semantics. But there are quite a few others too. For example:

• GNU targets traditionally provide access to naked functions and interrupt handlers through attributes.
• Different calling conventions also use attributes.
• The target attribute switches between ISAs in ways that do affect semantics.
• always_inline functions must be inlined for correctness.
• weak and visibility in effect alter the ODR.
• In GCC, functions that return twice (like setjmp) must be declared returns_twice.

It's unfortunate that using SME attributes will only trigger a warning in older compilers. The warning is enabled by default though. And in practice, I think most SME code would rely on other constructs that older compilers wouldn't provide, such as intrinsics.

[sdesmalen]

Gentle ping :)

[aaron.ballman]

Adding Erich as the new attributes code owner.

clang/include/clang/Basic/Attr.td

2435

Could you maybe give me an example here of what it looks like to apply the attribute to the function *type* when it's not allowed on the *declaration*? Does this all have to do with the position of the attribute in the declaration statement? When writing a function declaration it defines both the name and the type of that function, so there's no way to write a declaration without also defining its type.

Sure, but I'm going to use [[]] syntax to demonstrate the difference because it's very hard to reason about *what* a GNU-style attribute applies to given it's "sliding" behavior. C++ attributes have rules about what they appertain to based on syntactic location of the attribute so it's an easier way to demonstrate.

https://godbolt.org/z/Yz37fTbWY demonstrates some of the differences in terms of positioning of the attribute.
https://godbolt.org/z/18Y1Pn4se demonstrates the behavior when the type attribute matters for the type identify of the function.
https://godbolt.org/z/1jTqPx4f4 demonstrates another way in which a type attribute can matter.

For __attribute__ it's harder to reason about because of https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/attribute-syntax.html, especially because GCC and Clang don't always agree in terms of whether something can be used as a type attribute or not. But in terms of the mental model of attributes, the question really boils down to how much the attribute matters to the identity of the type -- if you don't want users to be able to assign an attributed function to a nonattributed function pointer (or vice versa), it most likely is a type attribute. If you think presence or absence of the attribute should impact things like overload resolution or template specializations, it's almost certainly a type attribute.

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

Yeah, we did consider using keywords instead. The main reason for sticking with GNU attributes is that they were specifically designed as an extensible way of attaching information or requirements to the source code, and they provide well-settled semantics. It seemed better to reuse an existing mechanism rather than invent something new.

If this is extra information the compiler is free to ignore without impacting program correctness, then I think an attribute is fine. But if the user's code will silently break if the attribute is ignored (e.g., an attribute ignored warning happens but the program successfully translates and does bad things at runtime), in some ways use of an attribute is far less ideal than use of a keyword-based attribute specifically because of the syntax error the user would get. Some users really like the "unknown attribute ignored" warning (like me!) and ensure it stays enabled and others users really don't like that warning and disable it. So it's dangerous to assume there's anything there worth relying on if the attributes have security implications at runtime.

Also, as C++ evolves, the semantics of GNU attributes evolve to match.

Errr does it? https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/attribute-syntax.html#attribute-syntax "There are some problems with the semantics of attributes in C++. For example, there are no manglings for attributes, although they may affect code generation, so problems may arise when attributed types are used in conjunction with templates or overloading. Similarly, typeid does not distinguish between types with different attributes. Support for attributes in C++ may be restricted in future to attributes on declarations only, but not on nested declarators." doesn't really seem to support that position.

A minor, but still nontrivial, reason is that there is less appetite in the GCC community for supporting target-specific extensions to the core language.

That's unfortunate given that _Keywords are reserved to the implementation specifically for this sort of thing. _Nullable is a good example of a successful attribute keyword. Attributes are a target-specific extension to the core language regardless of what syntax they use, so to me the driving question is more "what user experience do you want?" and less "is this an extension to the core language?"

[erichkeane]

clang/include/clang/AST/Type.h

3960

3973

We seem to be missing all of the modules-storage code for these. Since this is modifying the AST, we need to increment the 'breaking change' AST code, plus add this to the ASTWriter/ASTReader interface.

4171

Are they aware that includes; void Baz(); ?

[sdesmalen]

clang/include/clang/AST/Type.h

3973

Since this is modifying the AST, we need to increment the 'breaking change' AST code

Could you give me some pointers on what you expect to see changed here? I understand your point about adding this to the ASTWriter/Reader interfaces for module-storage, but it's not entirely clear what you mean by "increment the breaking change AST code".

I see there is also an ASTImporter, I guess this different from the ASTReader?

Please apologise my ignorance here, I'm not as familiar with the Clang codebase.

[erichkeane]

I also don't see anything in this with how it works with function pointer conversions, how it affects template instantiation, overload resolution/etc. If this is a type attribute, we need to specify all of that, probably in a separate document, since this is such a change to all those things.

clang/include/clang/AST/Type.h

3973

See VersionMajor here: https://clang.llvm.org/doxygen/ASTBitCodes_8h_source.html

Yes, ASTReader/ASTWriter and ASTImporter are different unfortunately. I'm not completely sure of the difference, but doing this patch changing the type here without doing those will break modules.

[aaron.ballman]

At some point, you should also add a release note to tell users about the new functionality.

clang/include/clang/AST/Type.h

4171

FWIW, the linked docs say:

> Functions like `some_func` and `another_func` are referred to as
> (K&R-style) “unprototyped” functions. The first C standard categorized
> them as an obsolescent feature and C18 removed all remaining support
> for them.

That's not quite accurate. They've always been obsolete in standard C (both ANSI and ISO C), so that's correct. But it's C2x that removes all remaining support for them. (Also, there's no such release as C18, there's C11, C17, and expected to be C23).

Are they aware that includes; void Baz(); ?

Just to expound on this question: this means void baz(); in C17 mode cannot have the attribute but void baz(); in C2x mode can. Folks coming from C++ tend to expect the C2x behavior to be the default and so it's plausible to see such signatures in older language modes. Will that cause any pain or confusion for you?

clang/include/clang/Basic/AttrDocs.td

6488

There are enough of these attributes that I think we should consider adding an ARM C Language Extensions for SME documentation category:

def DocCatACLE_SME : DocumentationCategory<"ARM C Language Extensions for SME"> {
  let Content = [{
Put general information about what ACLE SME is here to give an overview of the functionality and a place to link to the official ACLE SME documentation for more in-depth details.
}];
}

and then use this for the Category for each of the attributes so they group together.

6504–6506

I'm not certain I understand what this is telling me. The function is expected to be called with PSTATE.SM == 0 and return with it unchanged, so what does it mean for it to also require PSTATE.SM to be 1? I *think* it might be saying that the function is called with SM = 0 and returns with SM = 0, but within the function body itself SM will be 1?

6536–6537

Is acculator a typo or is that a term of art I am unfamiliar with?

6559–6566

If this is a hint, why is the attribute part of the type system? It seems like it'd be fine for the hint to be lost when forming a function pointer, as in:

__attribute__((arm_preserves_za)) void func(void);

void foo(void) {
  void (*fp)(void) = func; // Doesn't need to be an error, right?
}

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

Re-pinging this part of the thread -- the more I review this, the more it sounds like ignoring these attributes will cause a significant likelihood of the user's program silently misbehaving. Is that accurate? If so, I would reconsider whether using a keyword gives a more appropriate user experience for portability. With an attribute, the user has a very real chance of their code continuing to compile but not work. With a keyword, the user will get errors when porting to a compiler that doesn't support the keyword and are more protected from miscompiles. We can still reuse the vast majority of the implementation work already done here, so it should not be a major change to the implementation (a bit of extra parsing work for the keywords is really the only thing missing).

clang/lib/Basic/Targets/AArch64.cpp

589–590 ↗

(On Diff #471515)

I don't see any test coverage for these changes, and it seems orthogonal -- should this be split into its own review?

clang/lib/CodeGen/CGCall.cpp

2381–2397

The declaration won't have most of these attributes because they're type attributes, not declaration attributes. This looks like mostly dead code.

clang/lib/Sema/SemaDecl.cpp

3758–3765

How should these work with template (partial) specializations? Should it be invalid to write this on the primary template? Should it be invalid if the specialization doesn't match the primary template?

clang/lib/Sema/SemaDeclAttr.cpp

280

I think this is likely a good change but it seems orthogonal to the rest of the patch (it'd be helpful to more clearly see what test behavior this changes).

clang/lib/Sema/SemaDeclCXX.cpp

17692–17693

clang/lib/Sema/SemaType.cpp

7765

Pretty sure this should still work, assuming OtherAttr is an Attr * after stripping off the iterator.

7924–7948

Not your problem, but someday we should tablegen this kind of mutual exclusion the same as we've done for declaration and statement attributes.

[paulwalker-arm]

Hi @rsandifo-arm , what are your thoughts on Arron's observations? My interpretation is that Arm originally figured the distinction between keywords and gnu attributes was minimal and thus using our previous norms made most sense. This is not my world so my understanding is somewhat naive but it does sound like Arron has raised some good reasons why keywords are a better design decision. Do you agree? I wonder if it's worth having this conversation on https://github.com/ARM-software/abi-aa/pull/123 (unless Richard has a better link) so we can capture the rational for future design changes if any. @aaron.ballman, are you ok with this or do you prefer to keep the design conversation linked to this clang implementation?

[aaron.ballman]

In D127762#3930988, @paulwalker-arm wrote:

Hi @rsandifo-arm , what are your thoughts on Arron's observations? My interpretation is that Arm originally figured the distinction between keywords and gnu attributes was minimal and thus using our previous norms made most sense. This is not my world so my understanding is somewhat naive but it does sound like Arron has raised some good reasons why keywords are a better design decision. Do you agree? I wonder if it's worth having this conversation on https://github.com/ARM-software/abi-aa/pull/123 (unless Richard has a better link) so we can capture the rational for future design changes if any. @aaron.ballman, are you ok with this or do you prefer to keep the design conversation linked to this clang implementation?

I'm fine having that conversation on the design document rather than here on the review. We can use links to connect the dots between the design pull request and the phab review.

[rsandifo-arm]

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

I accept your points about the dangers of ignoring unsupported attributes. But this isn't an SME-specific issue. Ignoring the other GNU attributes I mentioned would also silently generate wrong code. I think this is a very strong argument against suppressing warnings about unrecognised GNU attributes by default, even if warnings about unrecognised standard attributes are eventually suppressed by default. (Perhaps they should even be controllable separately?) Like I say, there doesn't seem to have been a principle that GNU attributes provide information that the compiler is free to ignore.

If we did add keywords, would you be OK with giving them exactly the same semantics as GNU attributes? In other words, would it be acceptable to treat the keywords as essentially a one-for-one parsing replacement for GNU attributes? Or would you want the keyword to follow the same distinction between type properties and object properties as the standard attributes do?

[rsandifo-arm]

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

Or would you want the keyword to follow the same distinction between type properties and object properties as the standard attributes do?

That was a vague question, sorry. What I meant is whether the correct position of the keyword should vary based on whether it describes a property of the function type vs. a property of the function definition, or whether we can maintain the laxity in the GNU attribute positioning. I think the laxity in the GNU attribute positioning is helpful to users, and in this case wouldn't introduce any ambiguity.

From discussions I've had with people who will write/are writing SME code, the distinction between arm_locally_streamng being a property of the definition and arm_streaming being a property of the type seems contrived to them, especially when the usage of SME is private to a single translation unit.

Treating the keyword as an error-generating GNU attribute stand-in would also allow implementations to make the keyword as a preprocessor macro, if they need to.

[aaron.ballman]

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

If we did add keywords, would you be OK with giving them exactly the same semantics as GNU attributes?

The way we do keyword attributes is that the parser is responsible for parsing the keyword and kicking off the creation of the attribute in the proper place. For example: https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L928. This approach means there's plenty of flexibility available to parse the keyword where you think it makes sense.

That said, function types don't always allow for qualifiers (for example, free functions in C++ and all functions in C), so I would expect something more like _Keyword int func(); for functions and probably like int (* _Keyword)(); for function pointers. However, I agree that it's a bit more awkward for SME needs than the nullability attributes because the nullability attributes map directly onto qualifiers and so the question of 'where do we parse this' was very easy to answer.

All this said, if there's opposition to using keywords and a preference for attributes, that is okay by me (we have other type attributes). I was bringing it up mostly to make sure the design was considered explicitly rather than thinking an attribute was the only viable approach.

[rsandifo-arm]

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

The way we do keyword attributes is that the parser is responsible for parsing the keyword and kicking off the creation of the attribute in the proper place. For example: https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L928. This approach means there's plenty of flexibility available to parse the keyword where you think it makes sense.

That said, function types don't always allow for qualifiers (for example, free functions in C++ and all functions in C), so I would expect something more like _Keyword int func(); for functions and probably like int (* _Keyword)(); for function pointers.

Thanks. Having a consistent position like _Keyword int func(); for both kinds of attribute (decl and type) sounds good.

If we did add keywords, what kinds of spelling would you suggest? In the GNU attribute names we used the arm_ prefix as a kind of old-school namespace emulation. If the information had been suitable for standard attributes, we would obviously have used arm:: instead. However, using namespace-like prefixes might not be as natural for keywords, and I couldn't see any existing examples in TokenKinds.def. Would names like _NewZA/__new_za be OK? Would you recommend the CamelCase or lower_case style?

If we did use unprefixed keywords, would _Streaming/__streaming be acceptable for streaming functions? Or, since the term “streaming” is pretty generic, should we try to make the spelling more specific to AArch64 or SME?

Also, in terms of Clang direction, would it be acceptable to continue to add target-specific keywords for each new feature that compilers must interpret for correctness, and handle them directly in things like the parser case statements? Or should there be a more generic way of handling this, similar to Attr.td? The reason for asking is that it seems like the list of keywords could become quite long, just like Attr.td has. I don't think the SME attributes/information are particularly unusual, and it seems a lot of existing attributes would have been handled this way if we were starting from scratch, including all those that affect calling conventions. (There are some calling conventions that already have keywords, but there are some like preserve_most and preserve_all that seem to be handled by attributes only. There's also the Arm-specific aarch64_vector_pcs.)

[sdesmalen]

Addressed review comments. These include:

• Allow dropping the arm_preserves_za attribute.
• Added tests for serializing/deserializing the AST.
• Changed descriptions in documentation.

Also fixed an issue where the attributes would previously be silently be dropped when the function being converted to did not have a function prototype.

clang/include/clang/AST/Type.h

3973

So I tried to create some tests for this (see clang/test/AST/ast-dump-sme-attributes.cpp) and realised that the serialization/deserialization works out-of-the-box.

Does that mean all is needed is an increment of the VERSION_MAJOR or VERSION_MINOR number?

4171

@rsandifo-arm explained to me that it is indeed a deliberate choice not to support the attribute on unprototyped functions, as these are an obsolescent feature that will be removed in C2x. The mitigation should be trivial for new code that is written and it makes new code compliant with the next version of the standard.

clang/include/clang/Basic/Attr.td

2435

Thank you, those examples are very helpful!

clang/include/clang/Basic/AttrDocs.td

6504–6506

Yes, that's what I was trying to describe, albeit in a slightly confusing way :) I've rephrased it!

6536–6537

That was a typo, well spotted.

6559–6566

You're right, this should not lead to an error, the ACLE specification makes an exception for arm_preserves_za:

Function types with this attribute implicitly convert to function types that do not have the attribute. However, the reverse is not true.

I've fixed that and adjusted the test accordingly (both conversions are tested)

clang/lib/Basic/Targets/AArch64.cpp

589–590 ↗

(On Diff #471515)

This is actually tested in clang/test/Sema/aarch64-sme-attrs-no-sme.c, where it gives a warning diagnostic that the attribute is ignored when +sme is not specified.

clang/lib/CodeGen/CGCall.cpp

2381–2397

Good spot, I only need to handle aarch64_pstate_sm_body because that is a declaration attribute, not a type attribute.

clang/lib/Sema/SemaDecl.cpp

3758–3765

Can you share an example of what you're thinking of?

Do you mean something like:

template<typename T> void (*a)(T, T);
template<> __attribute__((arm_streaming)) void (*a<int>)(int, int);

where calling a<short>(0, 0) and a<int>(0, 0) have different streaming-mode behaviour? If so, then that is the intent. The SME attributes behave similar to a calling convention attributes, with the difference that more than one attribute can be applied.

clang/lib/Sema/SemaDeclAttr.cpp

280

It turns out this change is no longer needed, I'll remove it.

[aaron.ballman]

clang/include/clang/AST/Type.h

4171

Perfect, thank you for double-checking!

clang/include/clang/Basic/AttrDocs.td

6492

Double-checking: that macro is missing the trailing double underscore, is that expected?

clang/include/clang/Basic/DiagnosticSemaKinds.td

2000

If we did add keywords, what kinds of spelling would you suggest?

Ooof, yeah, you're asking some good questions about names! I'm hesitant to take names that are generic because of the potential for conflicts with other targets. However, for concepts like streaming, using _Streaming as the keyword is rather appealing too. The one scenario that really makes me think we should *not* use generic keywords is if the user tries to combine extensions. e.g., if ARM SVE uses _Streaming for one purpose and SYCL uses _Streaming for a slightly different purpose, it becomes impossible to use SYCL and ARM SVE together in some circumstances because we might not know which semantics to pick for any given use of the keyword. That makes me think _Arm_Streaming or __arm_streaming or whatever is a better approach. But as you point out, our existing keyword attributes don't encode a prefix in their names so this is novel. In terms of camel case vs lower case, I don't have a strong opinion on which to go with; we've used both in the past (__global and __constant vs _Nullable and, but __lower_case is by far the most prevalent spelling variety.

Also, in terms of Clang direction, would it be acceptable to continue to add target-specific keywords for each new feature that compilers must interpret for correctness, and handle them directly in things like the parser case statements? Or should there be a more generic way of handling this, similar to Attr.td?

I think we can probably tablegen more than we do already (for example, it would be nice for TokenKinds.def and Attr.td to be hooked together so you don't need to specify the spelling of the keyword in two places), but I'm not confident we can make it as general as attributes given the parsing implications. The closest idea I had would be to encode some kind of "this is a decl specifier" vs "this is a type specifier" vs "this is written on the declarator" kind of information in Attr.td, have some generic code in the parser that says "now parse keyword attributes in <whatever syntactic location>" that dispatches to some tablegenerated code which eats the correct tokens. However, I would expect this to be somewhat inflexible for parsing (e.g., ordering between keywords and other syntax) and maybe not suitable for all keyword attributes (parameterized keywords, for example). But if we started with the use cases we have, maybe it would generalize well enough to be worth it?

For reference, in terms of kinds of existing keywords in Attr.td, we have:

Decl: 8
Stmt: 0
Type: 16
Decl Or Stmt: 2
Decl Or Type: 8
Ignored: 1

So there's a reasonable variety of cases to have to think about for a generalized solution, but we could perhaps tackle them one at a time (start with type attributes because they're so popular and then add declaration attributes later and have more parsing locations).

[rsandifo-arm]

Thanks @aaron.ballman for the feedback about spellings. I've gone with the lower-case names like __arm_streaming in what follows, as a plausible strawman.

My main concern with keywords is:

This approach means there's plenty of flexibility available to parse the keyword where you think it makes sense.

If everyone parses keywords where it makes sense to them personally, for their specific use case, I'm worried that we'll end up with a lot of slightly different rules. (This tended to happen for pre-standard features, and like you say, is still the case for GNU attribute handling between Clang and GCC, given GCC's poorly-defined rules.)

For example, a type property like __arm_streaming only applies to functions, so it wouldn't make sense for bespoke rules to allow the keyword in tagged types or in array types. If a property only applies to object types then it wouldn't make sense for bespoke rules to allow the keyword after a parameter list.

So I think it makes sense to try to make the SME attributes an instance of a (new) generic solution. I think we want something “like standard attributes, but for semantic information”. That might sound like wanting something “like ice, but not cold”. But a lot of valuable work went into defining the parsing rules for standard attributes, and defining what they appertain to. It seems like a good idea to reuse those parts rather than reinvent the wheel.

https://reviews.llvm.org/D139028 is an RFC for adding “attribute-like keywords”: keywords that can appear exactly where a standard attribute can appear. This means that the keywords are syntactically valid in far more places than necessary for this initial use case, but it provides a simple and mechanical rule. And the keywords would have to be rejected in those additional places anyway, even if we don't parse them as attributes.

The covering note has a lot more justification (too much, sorry!). Does this look like a possible way forward?

Previously I was arguing in favour of the decl-to-type sliding rule, because:

From discussions I've had with people who will write/are writing SME code, the distinction between arm_locally_streamng being a property of the definition and arm_streaming being a property of the type seems contrived to them, especially when the usage of SME is private to a single translation unit.

Taking the RFC approach involves abandoning that and sticking strictly to the standard appurtenance rules. But hopefully it's a reasonable trade-off. The sliding rule is clearly going against the direction of travel anyway, so I'm probably being too Luddite there.

[sdesmalen]

Changed arm_new_za to be a declaration attribute instead of a type attribute (this was something that @rsandifo-arm pointed out to me recently)

[aaron.ballman]

In D127762#3960906, @rsandifo-arm wrote:

Thanks @aaron.ballman for the feedback about spellings. I've gone with the lower-case names like __arm_streaming in what follows, as a plausible strawman.

My main concern with keywords is:

This approach means there's plenty of flexibility available to parse the keyword where you think it makes sense.

If everyone parses keywords where it makes sense to them personally, for their specific use case, I'm worried that we'll end up with a lot of slightly different rules. (This tended to happen for pre-standard features, and like you say, is still the case for GNU attribute handling between Clang and GCC, given GCC's poorly-defined rules.)

Ah, I meant more that we have flexibility on what we want the grammar of the extension to be. If other implementations wanted to pick up the functionality, hopefully they'd pick up the same grammar as well.

For example, a type property like __arm_streaming only applies to functions, so it wouldn't make sense for bespoke rules to allow the keyword in tagged types or in array types. If a property only applies to object types then it wouldn't make sense for bespoke rules to allow the keyword after a parameter list.

Agreed, but that's a semantic property of the attribute rather than a syntactic property. We have control over both, of course, because this is our extension and we can define it how we like. But I was expecting we'd define a syntactic location to parse the attribute and we'd handle appertainance issues in SemaDeclAttr.cpp when deciding whether to convert the parsed attribute into a semantic attribute or not.

So I think it makes sense to try to make the SME attributes an instance of a (new) generic solution. I think we want something “like standard attributes, but for semantic information”. That might sound like wanting something “like ice, but not cold”. But a lot of valuable work went into defining the parsing rules for standard attributes, and defining what they appertain to. It seems like a good idea to reuse those parts rather than reinvent the wheel.

https://reviews.llvm.org/D139028 is an RFC for adding “attribute-like keywords”: keywords that can appear exactly where a standard attribute can appear. This means that the keywords are syntactically valid in far more places than necessary for this initial use case, but it provides a simple and mechanical rule. And the keywords would have to be rejected in those additional places anyway, even if we don't parse them as attributes.

FWIW, we already have a number of attributes implemented via a keyword today: ConstInitAttr, C11NoReturnAttr, a ton of CUDA and OpenCL keywords, calling conventions like __stdcall, etc. I'll take a look at the other patch to see what it's all about, but currently all keyword attributes need explicit parsing support added for them, as in: https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L4005 and https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaDecl.cpp#L7767.

The covering note has a lot more justification (too much, sorry!). Does this look like a possible way forward?

Previously I was arguing in favour of the decl-to-type sliding rule, because:

From discussions I've had with people who will write/are writing SME code, the distinction between arm_locally_streamng being a property of the definition and arm_streaming being a property of the type seems contrived to them, especially when the usage of SME is private to a single translation unit.

Taking the RFC approach involves abandoning that and sticking strictly to the standard appurtenance rules. But hopefully it's a reasonable trade-off. The sliding rule is clearly going against the direction of travel anyway, so I'm probably being too Luddite there.

Err, I'm struggling to see why the distinction is contrived. If the attribute applies to the type, then you get type-based semantics like the ability to overload or specialize on the presence/absence of the attribute -- you shouldn't get that behavior from a declaration attribute. e.g., if you use a declaration attribute on a function definition and then redefine the function without the attribute, that should give a redefinition error because that's two functions with the same name and same type being defined.

[rsandifo-arm]

In D127762#4023803, @aaron.ballman wrote:

In D127762#3960906, @rsandifo-arm wrote:

Thanks @aaron.ballman for the feedback about spellings. I've gone with the lower-case names like __arm_streaming in what follows, as a plausible strawman.

My main concern with keywords is:

This approach means there's plenty of flexibility available to parse the keyword where you think it makes sense.

If everyone parses keywords where it makes sense to them personally, for their specific use case, I'm worried that we'll end up with a lot of slightly different rules. (This tended to happen for pre-standard features, and like you say, is still the case for GNU attribute handling between Clang and GCC, given GCC's poorly-defined rules.)

Ah, I meant more that we have flexibility on what we want the grammar of the extension to be. If other implementations wanted to pick up the functionality, hopefully they'd pick up the same grammar as well.

Yeah, that's also how I was interpreting your comment. But my point is that, as the definers of this extension, we didn't really come into this needing/wanting custom grammar rules. The grammar for standard attributes would have been fine for us. We can't use those because standard attributes aren't allowed to affect semantics, but that's a rule imposed on us by the standard rather than a rule that we're imposing on ourselves. The grammar rules and the appurtenance rules would have been fine.

In other words, I agree that we have the flexibility to define specific rules for this extension that do whatever we want. But I don't think the extension is unusual enough to need that flexibility. There doesn't seem to be anything about the semantic function type properties in this extension that would require different grammar rules from other semantic function type properties. It seems better to have a generic way of attaching target-specific semantic information to types (and objects), just like the standard provides a generic way of attaching target-specific non-semantic information.

For example, a type property like __arm_streaming only applies to functions, so it wouldn't make sense for bespoke rules to allow the keyword in tagged types or in array types. If a property only applies to object types then it wouldn't make sense for bespoke rules to allow the keyword after a parameter list.

Agreed, but that's a semantic property of the attribute rather than a syntactic property. We have control over both, of course, because this is our extension and we can define it how we like. But I was expecting we'd define a syntactic location to parse the attribute and we'd handle appertainance issues in SemaDeclAttr.cpp when deciding whether to convert the parsed attribute into a semantic attribute or not.

Like you say, I think we're in agreement here, but approaching it from different angles. What I meant is that, if we add grammar rules that apply only to the keywords defined in this extension, those grammar rules would probably not allow the keyword to appear in things like tagged types or array types, because they would never be needed there. If each extension defines its own grammar rules, those rules would generally not allow keywords to appear in places where the keywords are always semantically invalid (although see below). This reduces the extent to which bespoke grammar rules for one extension can be cut-&-pasted into another extension.

Having grammar rules that are defined robotically based on the standard attribute grammar rules, rather than trying to tailor the grammar rules specifically to SME, should make it much more likely that the same grammar rules can be reused by later extensions. Doing that moves all of the extension-specific constraint checking to semantic analysis, rather than splitting it between parsing and semantic analysis.

So I think it makes sense to try to make the SME attributes an instance of a (new) generic solution. I think we want something “like standard attributes, but for semantic information”. That might sound like wanting something “like ice, but not cold”. But a lot of valuable work went into defining the parsing rules for standard attributes, and defining what they appertain to. It seems like a good idea to reuse those parts rather than reinvent the wheel.

https://reviews.llvm.org/D139028 is an RFC for adding “attribute-like keywords”: keywords that can appear exactly where a standard attribute can appear. This means that the keywords are syntactically valid in far more places than necessary for this initial use case, but it provides a simple and mechanical rule. And the keywords would have to be rejected in those additional places anyway, even if we don't parse them as attributes.

FWIW, we already have a number of attributes implemented via a keyword today: ConstInitAttr, C11NoReturnAttr, a ton of CUDA and OpenCL keywords, calling conventions like __stdcall, etc. I'll take a look at the other patch to see what it's all about, but currently all keyword attributes need explicit parsing support added for them, as in: https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L4005 and https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaDecl.cpp#L7767.

Thanks for looking at the patch. And yeah, I've seen those other keywords, but I think they show examples of the points I was making above. For example, we have:

// Microsoft compatibility
case tok::kw___cdecl:      // struct foo {...} __cdecl      x;
case tok::kw___fastcall:   // struct foo {...} __fastcall   x;
case tok::kw___stdcall:    // struct foo {...} __stdcall    x;
case tok::kw___thiscall:   // struct foo {...} __thiscall   x;
case tok::kw___vectorcall: // struct foo {...} __vectorcall x;
  // We will diagnose these calling-convention specifiers on non-function
  // declarations later, so claim they are valid after a type specifier.
  return getLangOpts().MicrosoftExt;

This seems like a case where Microsoft defined grammar rules that allow the keywords in more places than strictly necessary, so that the job of rejecting them moves from parsing to semantic analysis. The grammar rules could instead have rejected the keywords in these locations. Both ways work, and as far as I can tell, there are no particular differences between the Microsoft extensions and the SME extensions that would suggest the SME extensions should take a different approach. So we could accept the SME keywords in the same places “for consistency”, or we could reject them on the basis that the keywords are never needed in that context (just like they aren't needed in that context for the Microsoft extension). The choice seems pretty arbitrary.

I think there's a danger that adding SME in a similar ad hoc way would increase the sense of arbitrariness for whoever adds the next similar extension. :-)

The covering note has a lot more justification (too much, sorry!). Does this look like a possible way forward?

Previously I was arguing in favour of the decl-to-type sliding rule, because:

From discussions I've had with people who will write/are writing SME code, the distinction between arm_locally_streamng being a property of the definition and arm_streaming being a property of the type seems contrived to them, especially when the usage of SME is private to a single translation unit.

Taking the RFC approach involves abandoning that and sticking strictly to the standard appurtenance rules. But hopefully it's a reasonable trade-off. The sliding rule is clearly going against the direction of travel anyway, so I'm probably being too Luddite there.

Err, I'm struggling to see why the distinction is contrived. If the attribute applies to the type, then you get type-based semantics like the ability to overload or specialize on the presence/absence of the attribute -- you shouldn't get that behavior from a declaration attribute. e.g., if you use a declaration attribute on a function definition and then redefine the function without the attribute, that should give a redefinition error because that's two functions with the same name and same type being defined.

Yeah, I agree it's not contrived from a compiler developer's point of view, or from the point of view of someone with a specific interesting in language semantics. But the users I talked to are experts in other fields who just use C++ as a tool. The common use case for them was to write a function with certain properties and then call it. From that basic use case, it doesn't matter (to them) whether certain properties appertain to the types and others to the declaration.

The difference would start to matter to them if they defined virtual functions (for example), or exported the SME-specific functions as an API. But that wasn't the use case they were considering.

[aemerson]

Gentle ping on this discussion. @aaron.ballman

[erichkeane]

So I still don't see this doing the module writing/reading part, which is necessary if you're making this part of the type.

I'd like to see more testing/thought put into how this interfaces with overloads and template resolution.

Finally, and this is something @aaron.ballman probably wants to answer: Is this sufficiently important that we're willing to take the additional overhead of 8 bits for each function type (plus an extra 8 bits for its prototype?). Memory wise, this seems a little costly.

clang/include/clang/AST/Type.h

3973

So its not just ast-dump that matters, it is what happens when these functions are exported from a module, and imported from another? Unless you make changes to those areas, this SME stuff will be lost, since you're making it part of the type.

clang/test/Sema/aarch64-sme-func-attrs.c

173

What happens with implicit instantiations? Can you make sure calling these doesn't lose the attribute? Our implicit instantiation mechanism has an opt-in for a lot of attributes/etc.

Additionally, can these be overloaded on in C++? I don't see any tests for this. Since they are part of the function type, is that deduced properly? (that is, a function pointer passed as template argument, does it pick up the right type, and does it end up as a separate template isntantiation?).

[aaron.ballman]

In D127762#4102436, @erichkeane wrote:

Finally, and this is something @aaron.ballman probably wants to answer: Is this sufficiently important that we're willing to take the additional overhead of 8 bits for each function type (plus an extra 8 bits for its prototype?). Memory wise, this seems a little costly.

It'd be nice to have a rough idea of what the overhead costs are. I think we can steal a few bits back to reduce memory overhead if necessary.

clang/include/clang/AST/Type.h

4171

We could steal two bits back here and make this a 6-bit bit-field (we'd probably want to adjust SME_AttributeMask accordingly as well).

clang/include/clang/Basic/AttrDocs.td

6492

Still wondering on this.

clang/lib/Sema/SemaDecl.cpp

3758–3765

Yup, that's the scenario I was wondering about -- thanks for the answer (and I see test coverage for the situation as well).

[erichkeane]

In D127762#4102526, @aaron.ballman wrote:

In D127762#4102436, @erichkeane wrote:

Finally, and this is something @aaron.ballman probably wants to answer: Is this sufficiently important that we're willing to take the additional overhead of 8 bits for each function type (plus an extra 8 bits for its prototype?). Memory wise, this seems a little costly.

It'd be nice to have a rough idea of what the overhead costs are. I think we can steal a few bits back to reduce memory overhead if necessary.

I just have knowing how much memory per-function-type, which is 2 bytes per at the moment it looks (1 for the function type, 1 for the prototype). Reducing it to 6 bits saves us 1 of those bytes I think, but the one on FunctionTypeExtraBitfields doesn't save us anything. That said... its entirely possible to make it cost nothing there now that I look... It is align-as void*, so align 4 or 8 depending on the platform. It currently contains a single unsigned (so 4 bytes) for the number of types in an exception spec. So on 64 bit systems, we currently don't use any additional memory there as far as I can tell, but on 32 bit systems this likely costs 32 bits there (despite being an 8 bit bitfield).

By standard imp-limits, apparently we only need to handle 8 bits worth for the Exception Spec types. I'd be tempted, based on exception specs being deprecated and rarely used, to reduce it to an 'unsigned short' (2 bytes), which makes this cost-free on 32 bit machines. WDYT?

clang/include/clang/AST/Type.h

4171

That would be nice at least here, since Variadic/TrailingReturn would use the other 2, and mean that htis takes zero more data, instead of an entire additional byte.

[aaron.ballman]

In D127762#4102578, @erichkeane wrote:

By standard imp-limits, apparently we only need to handle 8 bits worth for the Exception Spec types. I'd be tempted, based on exception specs being deprecated and rarely used, to reduce it to an 'unsigned short' (2 bytes), which makes this cost-free on 32 bit machines. WDYT?

It's a bit orthogonal to this patch, but I think it's a reasonable change to make so long as we don't break significant code.

[bryanpkc]

@sdesmalen @rsandifo-arm @aaron.ballman @erichkeane What is the plan for this patch? Is it going to be abandoned in favor of D139028, or can it be landed in its current form after addressing all outstanding review comments?

[sdesmalen]

• Rebased patch after patch to add RegularKeyword attributes (D148702) landed
• Split off the request to reduce the size of FunctionTypeExtraBitfields (and use alignment of the struct to pointer type) to a new patch: D152140
• Added test to ensure that the serialization of type attributes is exported/imported to/from modules, see clang/test/Modules/aarch64-sme-keywords.cppm
• Added some new tests for template instantiation and function overloading with SME attributes:

void normal_func(void) {}
void streaming_func(void) __arm_streaming {}

template<typename T> int test_templated_f(T);
template<> constexpr int test_templated_f<void(*)(void)>(void(*)(void)) { return 1; }
template<> constexpr int test_templated_f<void(*)(void)__arm_streaming>(void(*)(void)__arm_streaming) { return 2; }

static_assert(test_templated_f(&normal_func) == 1, "Instantiated to wrong function");
static_assert(test_templated_f(&streaming_func) == 2, "Instantiated to wrong function");

and

// expected-cpp-error@+2 {{'__arm_streaming' only applies to function types; type here is 'int'}}
// expected-error@+1 {{'__arm_streaming' only applies to function types; type here is 'int'}}
int invalid_type_for_attribute __arm_streaming;

// Test overloads
constexpr int overload(void f(void)) { return 1; }
constexpr int overload(void f(void) __arm_streaming) { return 2; }
static_assert(overload(&normal_func) == 1, "Overloaded to wrong function");
static_assert(overload(&streaming_func) == 2, "Overloaded to wrong function");

[sdesmalen]

• Use only 6 bits for AArch64SMEAttributes to reduce the size of ExtProtoInfo.
• Added test for implicit instantiation.

[sdesmalen]

clang/include/clang/AST/Type.h

3973

Hi @erichkeane I've added a test for module export/import and was surprised to see this work without any additional changes. Do you think the added test is correct/sufficient to show that this works?

clang/include/clang/Basic/AttrDocs.td

6492

Sorry I missed that comment earlier. This is indeed intentional, there is no trailing __ after __ARM_FEATURE_SME.
The macro is defined here: https://github.com/ARM-software/acle/blob/main/main/acle.md#scalable-matrix-extension-sme

clang/test/Sema/aarch64-sme-func-attrs.c

173

I've added a few tests for these cases!

[erichkeane]

clang/include/clang/AST/Type.h

3973

I don't have a good idea of that, I know little about our modules implementation. Perhaps @ChuanqiXu knows?

[erichkeane]

We ended up getting the regular-attribute-like-keywords patch in a different form. Do we still want to do this as is? Does it need rebasing?

[sdesmalen]

In D127762#4395509, @erichkeane wrote:

We ended up getting the regular-attribute-like-keywords patch in a different form. Do we still want to do this as is? Does it need rebasing?

I've rebased this patch on top of @rsandifo-arm's patches so that it uses the attribute-like-keywords now (note for example that the tests have been updated to use the new keywords).

D148700 and D148702 only addressed the parsing side of things, not the semantics. This patch adds the remaining attributes/keywords (D148700 only added __arm_streaming), integrates the type information into the AST and adds codegen to the LLVM IR function- and call-site attributes.

[erichkeane]

I think we need a few tests to ensure that these are properly propagated on function templates (both for Sema and codegen). Also, a handful of nits (See my list).

clang/include/clang/AST/Type.h

3958

clang/include/clang/Basic/Attr.td

2459

So, why are __arm_shared_za and __arm_preserves_za different tenses, despite being very similar sounding? Should it be __arm_shares_za (or alternatively, __arm_preserved_za)?

clang/include/clang/Basic/AttrDocs.td

6595

I'm missing a touch of context that an additional word or two might help. is this 'the function requires the 'target' processor has SME? or the 'runtime' processor?

Also, the rest of the list ends in a '.', but this one doesnt.

6633

"ZA" should be defined 1st time it is used in this doc, and the ones below.

6635

Same comments as above.

6679

Same here.

6707

again.

clang/lib/Sema/SemaDecl.cpp

3758

clang/lib/Sema/SemaDeclAttr.cpp

9444

This switch should ONLY be 'handle' function calls. Please break this off into its own function.

[sdesmalen]

Updated patch:

• Addressed review comments (clarified documentation, minor refactoring)
• Added new tests (codegen + sema tests to make sure attributes are propagated to types when using variadic templates). If there's any other specific tests you'd like me to add, let me know.

I waited a bit to update this patch, because I wasn't sure if the syntax might still change pending the conversation on D148700, but at the moment the status is that the keywords have a specific benefit over C++ style attributes in that they are not silently ignored. If the concensus on this changes we can easily support the other syntax through another patch. I hope this patch with semantic support can land if everyone is happy with the implementation. I think I've addressed all outstanding comments now.

clang/include/clang/AST/Type.h

3973

Gentle ping @ChuanqiXu

Do you know if this patch requires any further changes for reading/writing modules? The test I've added seems to work fine.

clang/include/clang/Basic/Attr.td

2459

I think this was mostly for historical reasons. @rsandifo-arm mentioned to me that he was still open to renaming these.

[sdesmalen]

Gentle ping @aaron.ballman and @erichkeane. I've addressed all comments and suggestions and believe we found agreement on the approach (to use a keyword instead of an attribute).
Are you happy to accept the patch?

[rsandifo-arm]

Mostly LGTM from a spec POV, but some comments below.

clang/include/clang/Basic/Attr.td

2440

In current main, this attribute is gated on TargetAArch64 rather than TargetAArch64SME. The reason is that, from a QoI point of view, I don't think we should require the +sme extension in order to accept an __arm_streaming type. +sme is instead required to compile a function with __arm_streaming type, or a call to a function with __arm_streaming type. IMO those are more CodeGen rather than Sema restrictions.

E.g., if a header file contains

void sme_foo(void) __arm_streaming;

then an __attribute__((target_version("sme"))) function should be able to call it. But we shouldn't require +sme to be passed on the command line in order to compile the declaration of sme_foo.

I think the same principle applies to the other function-type attributes. In particular, __arm_preserves_za functions and __arm_streaming_compatible functions do not require SME to be present.

I think we should also allow:

__arm_locally_streaming void __attribute__((target_version("sme"))) ifunc() { … }

since __arm_locally_streaming does not change the function signature.

So I think all of these attributes should be gated on TargetAArch64, with checks for SME made elsewhere where necessary.

(Unfortunately, since command-line options are out of scope for ACLE, I don't think it can really specify this.)

clang/include/clang/Basic/AttrDocs.td

6561

The bullet was trying to describe the function's ABI. I don't think “target” is appropriate in an ABI context (where you might be describing a binary that already exists, rather than a compilation). So I've a slight preference for dropping “target”.

I see in another comment, Erich made a distinction between “target” and “run-time”. If we do use one or the other, I think “run-time” is more correct.

“target” is right for __arm_locally_streaming and __arm_new_za though.

6595

How about “non-streaming” rather than “normal”?

6598

6638

The other type attributes also only describe normal returns.

6710

Just trying to avoid “if available”, since the saves aren't being provided for the benefit of anyone else. Feel free to reword to something else.

clang/include/clang/Basic/DiagnosticSemaKinds.td

3591–3592

clang/lib/AST/Type.cpp

3536

This comment probably needs updating for the new field, although the comment already seems pretty out of date. (It looks like the separate bool was removed in 2011.)

I suppose the new field doesn't create any ambiguities because it's always present. But given the comment about performance sensitivity, I wonder if we should combine the new field with the trailing return flag?

clang/lib/AST/TypePrinter.cpp

943

Are the !InsideCCAttribute conditions necessary? AIUI, InsideCCAttribute exists to suppress the default calling convention when printing the type to which an explicit CC is added. That doesn't apply to SME attributes, because they aren't modelled as traditional CCs, and because the default/normal case doesn't have any syntax associated with it.

clang/lib/CodeGen/CodeGenModule.cpp

2073

How about something like:

// Handle SME attributes that apply to function definitions,
// rather than to function prototypes.

I can see why the current comment helped when we were still using GNU attributes, due to the way that type attributes “slid” from the declaration to the type. But now that the attributes are non-sliding type attributes, it wouldn't make sense to query D->hasAttr for them.

The suggested change also avoids the contradiction between “we only need to” and “the same holds for”.

clang/lib/Sema/SemaExpr.cpp

9565

The meaning of “from” and “to” seem to be the opposite of what I'd initially assumed. For casts, I'd have expected the type of the object that is being casted to have FromType and the cast type (the type of the result) to be ToType. Dropping ZA would then mean that FromAttributes has __arm_preserves_za and ToType doesn't.

I think that also makes sense for the virtual function check above. The overriding function has FromType and the function it overrides has ToType. We need to be able to convert from FromType to ToType (e.g. to initialise the vtable), but don't need to be able to go the other way.

clang/test/Sema/aarch64-sme-func-attrs.c

58

Is it not possible to address this FIXME yet? Might be worth expanding the comment to say why if so.

185

I think it'd be worth having a few more of these, in particular testing that an override can be __arm_shared_za __arm_preserves_za if it wants to be.

[aaron.ballman]

In D127762#4515055, @sdesmalen wrote:

Gentle ping @aaron.ballman and @erichkeane. I've addressed all comments and suggestions and believe we found agreement on the approach (to use a keyword instead of an attribute).
Are you happy to accept the patch?

I think things are looking close, still some minor issues to correct though.

clang/include/clang/AST/Type.h

3969–3990

I think this should also be an unsigned bit-field so that it packs together with the new field added below. Otherwise we're liable to end up with padding between this field and the next bit-field (which will take a full allocation unit anyway). How about unsigned NumExceptionType : 10;? We're reducing the count by 6 bits, but.... I struggle to imagine code being impacted and we're still allowing more than the implementation limits require.

4169–4172

IIRC, at least one of the compilers used to build Clang has issues with adjacent bit-fields of differing types, so we'd usually make these bool fields be unsigned at this point to ensure they pack together properly.

4201–4202

Isn't the more idiomatic form of this written as AArch64SMEAttributes &= ~Kind;?

clang/include/clang/Basic/AttrDocs.td

6595

non-streaming sounds good to me.

clang/include/clang/Basic/DiagnosticSemaKinds.td

3591–3592

Also, remove the single quotes around %0 and %1 -- you're getting duplicate quotes in the test cases because of them.

clang/lib/Sema/SemaType.cpp

7912

[sdesmalen]

• The attributes no longer require +sme to be passed.
• Fixed IsInvalidSMECallConversion to consider the correct To/From types and added a corresponding test for the virtual override functions.
• Created a new category for the Arm SME attributes in the Clang Attributes document.
• Addressed all other comments.

[sdesmalen]

Thanks both for the detailed review and latest round of comments, I've tried to address them all.

clang/include/clang/AST/Type.h

3969–3990

That's what I did initially in the patch where I limited NumExceptionType to 16bits (D152140), but there was the preference to have this be a uint16_t instead. I've changed it back again to a bitfield though.

clang/include/clang/Basic/Attr.td

2440

That's a fair point. This change was partially made in D152141, so I've updated both patches to reflect the right behaviour.

clang/include/clang/Basic/AttrDocs.td

6488

@rsandifo-arm pointed out that I marked this comment as done, but hadn't done it. I've fixed that now, and created a new category for the SME extensions.

clang/include/clang/Basic/DiagnosticSemaKinds.td

3591–3592

Thanks! That explains the double quotes indeed.

clang/lib/AST/TypePrinter.cpp

943

You're right, they were not necessary! Thanks.

clang/lib/Sema/SemaExpr.cpp

9565

Thanks for pointing out, that was indeed wrong. I've fixed it, and added a test-case for the virtual function override for the __arm_preserves_za case.

clang/test/Sema/aarch64-sme-func-attrs.c

58

This was a stale comment, these cases are checked later on in section:

// 
// Check for incorrect conversions of function pointers with the attributes
//

[aaron.ballman]

LGTM, though please give other active reviewers a bit of time to chime in before landing. Note, @erichkeane is out on sabbatical at the moment, so there's no need to wait for his LG (he can leave post-commit comments on the review when he gets back though, so keep your eyes peeled for that just in case).

clang/include/clang/AST/Type.h

3969–3990

I'm sorry for the back and forth! I think Erich's suggestion was wrong in the other thread, mostly because of MSVC: https://godbolt.org/z/W9fn7Ghxo

[rsandifo-arm]

Thanks for dropping the attribute requirements down to TargetAArch64. But the offsetting requirement was that something somewhere (CodeGen?) must raise an error if code requires SME and SME isn't present. I think that means:

1. SME is not enabled for an __arm_streaming or __arm_locally_streaming function definition.
2. SME is not enabled for a call to an __arm_streaming function.
3. SME is not enabled for an __arm_shared_za or __arm_new_za function definition.

(Calls to __arm_shared_za functions don't need to be listed explicitly, since only __arm_shared_za and __arm_new_za functions can make such calls.)

In all cases, the check would apply after __attribute__((target_version)) is taken into account.

Perhaps that's a separate patch though.

clang/include/clang/Basic/AttrDocs.td

6590

clang/test/Sema/aarch64-sme-func-attrs.c

187

Thanks, this is indeed the case I was suggesting to test. But my point was that it shouldn't be an error. It's OK for an override to be __arm_preserves_za even if the function it overrides isn't. Something that calls shared_za_member directly from an S2_2 object can take advantage of the extra guarantee.

It's the other way that's wrong. If a virtual function is __arm_preserves_za then any override must be too.

The principle is similar to covariant return types. E.g.:

struct S1 { virtual S1 *f(); };
struct S2 : S1 { S2 *f() override; }; // OK
struct S3 : S2 { S2 *f() override; }; // OK
struct S4 : S3 { S1 *f() override; }; // Error

An __arm_preserves_za function acts like functions that return S2 * in this example, and a non-__arm_preserves_za function acts like functions that return S1 *.

[sdesmalen]

Added enum AArch64SMECallConversionKind to make it explicit when calling
IsInvalidSMECallConversion whether or not 'preserves_za' can be dropped
(e.g. in assignment), can be added (e.g. when overriding a parent method)
or must match exactly (e.g. when redefining a function).

I'll post a separate patch for guarding the SME attributes when not
compiling for a target with sme.

[rsandifo-arm]

LGTM too, thanks.

clang/include/clang/AST/Type.h

public:
     }
   };
 
   /// A simple holder for a QualType representing a type in an
   /// exception specification. Unfortunately needed by FunctionProtoType
   /// because TrailingObjects cannot handle repeated types.
   struct ExceptionType { QualType Type; };
 
+  /// The AArch64 SME ACLE (Arm C/C++ Language Extensions) define a number
+  /// of function type attributes that can be set on function types, including
+  /// function pointers.
+  enum AArch64SMETypeAttributes : unsigned {
+    SME_NormalFunction = 0,
+    SME_PStateSMEnabledMask = 1 << 0,
+    SME_PStateSMCompatibleMask = 1 << 1,
+    SME_PStateZASharedMask = 1 << 2,
+    SME_PStateZAPreservedMask = 1 << 3,
+    SME_AttributeMask = 63 // We only support maximum 6 bits because of the
+                           // bitmask in FunctionTypeExtraBitfields.
+  };
+
   /// A simple holder for various uncommon bits which do not fit in
   /// FunctionTypeBitfields. Aligned to alignof(void *) to maintain the
   /// alignment of subsequent objects in TrailingObjects.
   class alignas(void *) FunctionTypeExtraBitfields {
     /// The number of types in the exception specification.
     /// A whole unsigned is not needed here and according to
     /// [implimits] 8 bits would be enough here.
     unsigned NumExceptionType : 16;
 
+    /// Any AArch64 SME ACLE type attributes that need to be propagated
+    /// on declarations and function pointers.
+    unsigned AArch64SMEAttributes : 6;
+
   public:
-    FunctionTypeExtraBitfields() : NumExceptionType(0) {}
+    FunctionTypeExtraBitfields()
+        : NumExceptionType(0), AArch64SMEAttributes(SME_NormalFunction) {}
 
     void setNumExceptionType(unsigned N) {
       assert(N < 65536 && "Not enough bits to encode exceptions");
       NumExceptionType = N;
     }
     unsigned getNumExceptionType() const { return NumExceptionType; }
+
+    void setAArch64SMEAttributes(unsigned Attrs) {
+      assert(Attrs <= SME_AttributeMask &&
+             "Not enough bits to encode SME attributes");
+      AArch64SMEAttributes = Attrs;
+    }
+    unsigned getAArch64SMEAttributes() const { return AArch64SMEAttributes; }
   };
 
 protected:
   FunctionType(TypeClass tc, QualType res, QualType Canonical,
                TypeDependence Dependence, ExtInfo Info)
       : Type(tc, Canonical, Dependence), ResultType(res) {
     FunctionTypeBits.ExtInfo = Info.Bits;
   }

 public:
   // No additional state past what FunctionType provides.
 
   bool isSugared() const { return false; }
   QualType desugar() const { return QualType(this, 0); }
 
   void Profile(llvm::FoldingSetNodeID &ID) {
     Profile(ID, getReturnType(), getExtInfo());
   }
 
   static void Profile(llvm::FoldingSetNodeID &ID, QualType ResultType,
                       ExtInfo Info) {
     Info.Profile(ID);
     ID.AddPointer(ResultType.getAsOpaquePtr());
   }
 
   static bool classof(const Type *T) {
struct ExceptionSpecInfo {
     ExceptionSpecInfo(ExceptionSpecificationType EST) : Type(EST) {}
   };
 
   /// Extra information about a function prototype. ExtProtoInfo is not
   /// stored as such in FunctionProtoType but is used to group together
   /// the various bits of extra information about a function prototype.
   struct ExtProtoInfo {
     FunctionType::ExtInfo ExtInfo;
     bool Variadic : 1;
     bool HasTrailingReturn : 1;
+    unsigned AArch64SMEAttributes : 6;
     Qualifiers TypeQuals;
     RefQualifierKind RefQualifier = RQ_None;
     ExceptionSpecInfo ExceptionSpec;
     const ExtParameterInfo *ExtParameterInfos = nullptr;
     SourceLocation EllipsisLoc;
 
-    ExtProtoInfo() : Variadic(false), HasTrailingReturn(false) {}
+    ExtProtoInfo()
+        : Variadic(false), HasTrailingReturn(false),
+          AArch64SMEAttributes(SME_NormalFunction) {}
 
     ExtProtoInfo(CallingConv CC)
-        : ExtInfo(CC), Variadic(false), HasTrailingReturn(false) {}
+        : ExtInfo(CC), Variadic(false), HasTrailingReturn(false),
+          AArch64SMEAttributes(SME_NormalFunction) {}
 
     ExtProtoInfo withExceptionSpec(const ExceptionSpecInfo &ESI) {
       ExtProtoInfo Result(*this);
       Result.ExceptionSpec = ESI;
       return Result;
     }
 
     bool requiresFunctionProtoTypeExtraBitfields() const {
-      return ExceptionSpec.Type == EST_Dynamic;
+      return ExceptionSpec.Type == EST_Dynamic ||
+             AArch64SMEAttributes != SME_NormalFunction;
+    }
+
+    void setArmSMEAttribute(AArch64SMETypeAttributes Kind, bool Enable = true) {
+      if (Enable)
+        AArch64SMEAttributes |= Kind;
+      else
+        AArch64SMEAttributes =
+            (AArch64SMEAttributes ^ Kind) & AArch64SMEAttributes;
     }
   };
 
 private:
   unsigned numTrailingObjects(OverloadToken<QualType>) const {
     return getNumParams();
   }
 
ExtProtoInfo getExtProtoInfo() const {
     EPI.ExtInfo = getExtInfo();
     EPI.Variadic = isVariadic();
     EPI.EllipsisLoc = getEllipsisLoc();
     EPI.HasTrailingReturn = hasTrailingReturn();
     EPI.ExceptionSpec = getExceptionSpecInfo();
     EPI.TypeQuals = getMethodQuals();
     EPI.RefQualifier = getRefQualifier();
     EPI.ExtParameterInfos = getExtParameterInfosOrNull();
+    EPI.AArch64SMEAttributes = getAArch64SMEAttributes();
     return EPI;
   }
 
   /// Get the kind of exception specification on this function.
   ExceptionSpecificationType getExceptionSpecType() const {
     return static_cast<ExceptionSpecificationType>(
         FunctionTypeBits.ExceptionSpecType);
   }
public:
   /// information, if present, or else null if none of the parameters
   /// carry it.  This is equivalent to getExtProtoInfo().ExtParameterInfos.
   const ExtParameterInfo *getExtParameterInfosOrNull() const {
     if (!hasExtParameterInfos())
       return nullptr;
     return getTrailingObjects<ExtParameterInfo>();
   }
 
+  /// Return a bitmask describing the SME attributes on the function type, see
+  /// AArch64SMETypeAttributes for their values.
+  unsigned getAArch64SMEAttributes() const {
+    if (!hasExtraBitfields())
+      return SME_NormalFunction;
+    return getTrailingObjects<FunctionTypeExtraBitfields>()
+        ->getAArch64SMEAttributes();
+  }
+
   ExtParameterInfo getExtParameterInfo(unsigned I) const {
     assert(I < getNumParams() && "parameter index out of range");
     if (hasExtParameterInfos())
       return getTrailingObjects<ExtParameterInfo>()[I];
     return ExtParameterInfo();
   }
 
   ParameterABI getParameterABI(unsigned I) const {

clang/include/clang/AST/TypeProperties.td

let Class = FunctionProtoType in {
   def : Property<"parameters", Array<QualType>> {
     let Read = [{ node->getParamTypes() }];
   }
   def : Property<"extParameterInfo", Array<ExtParameterInfo>> {
     let Read = [{ node->hasExtParameterInfos()
                     ? node->getExtParameterInfos()
                     : llvm::ArrayRef<FunctionProtoType::ExtParameterInfo>() }];
   }
+  def : Property<"AArch64SMEAttributes", UInt32> {
+    let Read = [{ node->getAArch64SMEAttributes() }];
+  }
 
   def : Creator<[{
     auto extInfo = FunctionType::ExtInfo(noReturn, hasRegParm, regParm,
                                          callingConvention, producesResult,
                                          noCallerSavedRegs, noCfCheck,
                                          cmseNSCall);
     FunctionProtoType::ExtProtoInfo epi;
     epi.ExtInfo = extInfo;
     epi.Variadic = variadic;
     epi.HasTrailingReturn = trailingReturn;
     epi.TypeQuals = methodQualifiers;
     epi.RefQualifier = refQualifier;
     epi.ExceptionSpec = exceptionSpecifier;
     epi.ExtParameterInfos =
       extParameterInfo.empty() ? nullptr : extParameterInfo.data();
+    epi.AArch64SMEAttributes = AArch64SMEAttributes;
     return ctx.getFunctionType(returnType, parameters, epi);
   }]>;
 }
 
 let Class = AtomicType in {
   def : Property<"valueType", QualType> {
     let Read = [{ node->getValueType() }];
   }

clang/include/clang/Basic/Attr.td

 def ObjCDirectMembers : Attr {
   let Spellings = [Clang<"objc_direct_members">];
   let Subjects = SubjectList<[ObjCImpl, ObjCInterface, ObjCCategory], ErrorDiag>;
   let LangOpts = [ObjC];
   let Documentation = [ObjCDirectMembersDocs];
 }
 
 def ObjCNonRuntimeProtocol : Attr {
   let Spellings = [Clang<"objc_non_runtime_protocol">];
   let Subjects = SubjectList<[ObjCProtocol], ErrorDiag>;
   let LangOpts = [ObjC];
   let Documentation = [ObjCNonRuntimeProtocolDocs];
   let SimpleHandler = 1;
 }
 
 def ObjCRuntimeName : Attr {
   let Spellings = [Clang<"objc_runtime_name">];
   let Subjects = SubjectList<[ObjCInterface, ObjCProtocol], ErrorDiag>;
   let Args = [StringArgument<"MetadataName">];
   let Documentation = [ObjCRuntimeNameDocs];
 }
 
 def ObjCRuntimeVisible : Attr {
   let Spellings = [Clang<"objc_runtime_visible">];
   let Subjects = SubjectList<[ObjCInterface], ErrorDiag>;
   let Documentation = [ObjCRuntimeVisibleDocs];
   let SimpleHandler = 1;
 }
 
//  let Subjects = [Function, ObjCMethod];
   let Documentation = [PcsDocs];
 }
 
 def AArch64VectorPcs: DeclOrTypeAttr {
   let Spellings = [Clang<"aarch64_vector_pcs">];
   let Documentation = [AArch64VectorPcsDocs];
 }
 
 def AArch64SVEPcs: DeclOrTypeAttr {
   let Spellings = [Clang<"aarch64_sve_pcs">];
   let Documentation = [AArch64SVEPcsDocs];
 }
 
 def ArmStreaming : TypeAttr, TargetSpecificAttr<TargetAArch64SME> {
   let Spellings = [RegularKeyword<"__arm_streaming">];
   let Subjects = SubjectList<[HasFunctionProto], ErrorDiag>;
   let Documentation = [ArmSmeStreamingDocs];
 }
 
+def ArmStreamingCompatible : TypeAttr, TargetSpecificAttr<TargetAArch64SME> {
+  let Spellings = [RegularKeyword<"__arm_streaming_compatible">];
+  let Subjects = SubjectList<[HasFunctionProto], ErrorDiag>;
+  let Documentation = [ArmSmeStreamingCompatibleDocs];
+}
+
+def ArmSharedZA : TypeAttr, TargetSpecificAttr<TargetAArch64SME> {
+  let Spellings = [RegularKeyword<"__arm_shared_za">];
+  let Subjects = SubjectList<[HasFunctionProto], ErrorDiag>;
+  let Documentation = [ArmSmeSharedZADocs];
+}
+
+def ArmPreservesZA : TypeAttr, TargetSpecificAttr<TargetAArch64SME> {
+  let Spellings = [RegularKeyword<"__arm_preserves_za">];
+  let Subjects = SubjectList<[HasFunctionProto], ErrorDiag>;
+  let Documentation = [ArmSmePreservesZADocs];
+}
+
+def ArmLocallyStreaming : InheritableAttr, TargetSpecificAttr<TargetAArch64SME> {
+  let Spellings = [RegularKeyword<"__arm_locally_streaming">];
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+  let Documentation = [ArmSmeLocallyStreamingDocs];
+}
+
+def ArmNewZA : InheritableAttr, TargetSpecificAttr<TargetAArch64SME> {
+  let Spellings = [RegularKeyword<"__arm_new_za">];
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+  let Documentation = [ArmSmeNewZADocs];
+}
+def : MutualExclusions<[ArmNewZA, ArmSharedZA]>;
+def : MutualExclusions<[ArmNewZA, ArmPreservesZA]>;
+
+
 def Pure : InheritableAttr {
   let Spellings = [GCC<"pure">];
   let Documentation = [Undocumented];
   let SimpleHandler = 1;
 }
 
 def Regparm : TypeAttr {
   let Spellings = [GCC<"regparm">];

clang/include/clang/Basic/AttrDocs.td

 enabled under the ``-msve-vector-bits`` flag.
 
 For more information See `Arm C Language Extensions for SVE
 <https://developer.arm.com/documentation/100987/latest>`_ for more information.
 }];
 }
 
 def ArmMveStrictPolymorphismDocs : Documentation {
     let Category = DocCatType;
     let Content = [{
 This attribute is used in the implementation of the ACLE intrinsics for the Arm
 MVE instruction set. It is used to define the vector types used by the MVE
 intrinsics.
 
 Its effect is to modify the behavior of a vector type with respect to function
 overloading. If a candidate function for overload resolution has a parameter
 type with this attribute, then the selection of that candidate function will be
 disallowed if the actual argument can only be converted via a lax vector
 conversion. The aim is to prevent spurious ambiguity in ARM MVE polymorphic
 intrinsics.
 
 .. code-block:: c++
 
   void overloaded(uint16x8_t vector, uint16_t scalar);
   void overloaded(int32x4_t vector, int32_t scalar);
   uint16x8_t myVector;
   uint16_t myScalar;
 
   // myScalar is promoted to int32_t as a side effect of the addition,
   // so if lax vector conversions are considered for myVector, then
   // the two overloads are equally good (one argument conversion
   // each). But if the vector has the __clang_arm_mve_strict_polymorphism
   // attribute, only the uint16x8_t,uint16_t overload will match.
   overloaded(myVector, myScalar + 1);
 

 
 def ArmCmseNSCallDocs : Documentation {
   let Category = DocCatType;
   let Content = [{
 This attribute declares a non-secure function type. When compiling for secure
 state, a call to such a function would switch from secure to non-secure state.
 All non-secure function calls must happen only through a function pointer, and
 a non-secure function type should only be used as a base type of a pointer.
 See `ARMv8-M Security Extensions: Requirements on Development
 Tools - Engineering Specification Documentation
 <https://developer.arm.com/docs/ecm0359818/latest/>`_ for more information.
   }];
 }
 
 def ArmCmseNSEntryDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 This attribute declares a function that can be called from non-secure state, or
 from secure state. Entering from and returning to non-secure state would switch
 to and from secure state, respectively, and prevent flow of information
 to non-secure state, except via return values. See `ARMv8-M Security Extensions:
 Requirements on Development Tools - Engineering Specification Documentation
 <https://developer.arm.com/docs/ecm0359818/latest/>`_ for more information.
   }];
 }
 
 def ArmSmeStreamingDocs : Documentation {
   let Category = DocCatType;
   let Content = [{
-.. Note:: This attribute has not been implemented yet, but once it is
-   implemented, it will behave as described below.
-
 The ``__arm_streaming`` keyword is only available on AArch64 targets.
 It applies to function types and specifies that the function has a
 “streaming interface”.  This means that:
 
 * the function requires the Scalable Matrix Extension (SME)
 
 * the function must be entered in streaming mode (that is, with PSTATE.SM
   set to 1)
 
 * the function must return in streaming mode
 
 * the function does not have a K&R-style unprototyped function type.
 
 See `Procedure Call Standard for the Arm® 64-bit Architecture (AArch64)
 <https://github.com/ARM-software/abi-aa>`_ for more details about
 streaming-interface functions.
 
 Clang manages PSTATE.SM automatically; it is not the source code's
 responsibility to do this.  For example, if a normal non-streaming
 function calls an ``__arm_streaming`` function, Clang generates code
 that switches into streaming mode before calling the function and
 switches back to non-streaming mode on return.
 
 ``__arm_streaming`` can appear anywhere that a standard ``[[…]]`` type
 attribute can appear.
 
 See `Arm C Language Extensions <https://github.com/ARM-software/acle>`_
 for more details about this extension, and for other related SME features.
   }];
 }
 
+def ArmSmeStreamingCompatibleDocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+The ``__arm_streaming_compatible`` keyword is only available on AArch64 targets.
+It applies to function types and specifies that the function has a
+“streaming compatible interface”.  This means that:
+
+* the function requires the Scalable Matrix Extension (SME)
+
+* the function may be entered in either normal mode (PSTATE.SM=0) or
+  in streaming mode (PSTATE.SM=1).
+
+* the function must return in the same mode in which it entered the function.
+
+* the code executed in the function is compatible with either mode.
+
+* the function does not have a K&R-style unprototyped function type.
+
+See `Procedure Call Standard for the Arm® 64-bit Architecture (AArch64)
+<https://github.com/ARM-software/abi-aa>`_ for more details about
+streaming-compatible functions.
+
+Clang manages PSTATE.SM automatically; it is not the source code's
+responsibility to do this.  Clang will ensure that the generated code in
+streaming-compatible functions is valid in either mode (PSTATE.SM=0 or
+PSTATE.SM=1). For example, if an ``__arm_streaming_compatible`` function calls a
+normal function, Clang generates code to temporarily switch out of streaming
+mode before calling the function and switch back to streaming-mode on return if
+``PSTATE.SM`` is ``1`` on entry of the caller. If ``PSTATE.SM`` is ``0`` on
+entry to the ``__arm_streaming_compatible`` function, the call will be executed
+without changing modes.
+
+``__arm_streaming_compatible`` can appear anywhere that a standard ``[[…]]``
+type attribute can appear.
+
+See `Arm C Language Extensions <https://github.com/ARM-software/acle>`_
+for more details about this extension, and for other related SME features.
+  }];
+}
+
+def ArmSmeSharedZADocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+The ``__arm_shared_za`` keyword is only available on AArch64 targets.
+It applies to function types and specifies that the function shares
+ZA state with its caller.  This means that:
+
+* the function requires the Scalable Matrix Extension (SME)
+
+* the function enters with ZA in an active state.
+
+* the function returns with ZA in an active state for normal returns.
+
+* the function does not have a K&R-style unprototyped function type.
+
+See `Procedure Call Standard for the Arm® 64-bit Architecture (AArch64)
+<https://github.com/ARM-software/abi-aa>`_ for more details about shared-ZA
+functions.
+
+``__arm_shared_za`` can appear anywhere that a standard ``[[…]]``
+type attribute can appear.
+
+See `Arm C Language Extensions <https://github.com/ARM-software/acle>`_
+for more details about this extension, and for other related SME features.
+  }];
+}
+
+def ArmSmePreservesZADocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+The ``__arm_preserves_za`` keyword is only available on AArch64 targets.
+It applies to function types and specifies that the function does not
+modify ZA state.
+
+``__arm_preserves_za`` can appear anywhere that a standard ``[[…]]``
+type attribute can appear, however the keyword does not apply to functions
+having a K&R-style unprototyped function type.
+
+See `Arm C Language Extensions <https://github.com/ARM-software/acle>`_
+for more details about this extension, and for other related SME features.
+  }];
+}
+
+
+def ArmSmeLocallyStreamingDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The ``__arm_locally_streaming`` keyword is only available on AArch64 targets.
+It applies to function declarations and specifies that all the statements in the
+function are executed in streaming mode. This means that:
+
+* the function requires the Scalable Matrix Extension (SME)
+
+* the program automatically puts the machine into streaming mode before
+  executing the statements and automatically restores the previous mode
+  afterwards.
+
+Clang manages PSTATE.SM automatically; it is not the source code's
+responsibility to do this.  For example, Clang will emit code to enable
+streaming mode at the start of the function, and disable streaming mode
+at the end of the function.
+
+``__arm_locally_streaming`` can appear anywhere that a standard ``[[…]]``
+declaration attribute can appear.
+
+See `Arm C Language Extensions <https://github.com/ARM-software/acle>`_
+for more details about this extension, and for other related SME features.
+  }];
+}
+
+def ArmSmeNewZADocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The ``__arm_new_za`` keyword is only available on AArch64 targets.
+It applies to function declarations and specifies that the function will be set
+up with a fresh ZA context.
+
+This means that:
+
+* the function requires the Scalable Matrix Extension (SME)
+
+* the function will commit any lazy-saves if available.
+
+* the function will create a new ZA context and enable PSTATE.ZA.
+
+* the function will disable PSTATE.ZA (by setting it to 0) before returning.
+
+For ``__arm_new_za`` functions Clang will set up the ZA context automatically
+on entry to the function, and disable it before returning. For example, if ZA is
+in a dormant state Clang will generate the code to commit a lazy-save and set up
+a new ZA state before executing user code.
+
+``__arm_new_za`` can appear anywhere that a standard ``[[…]]`` declaration
+attribute can appear.
+
+See `Arm C Language Extensions <https://github.com/ARM-software/acle>`_
+for more details about this extension, and for other related SME features.
+  }];
+}
+
 def AlwaysInlineDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 Inlining heuristics are disabled and inlining is always attempted regardless of
 optimization level.
 
 ``[[clang::always_inline]]`` spelling can be used as a statement attribute; other
 spellings of the attribute are not supported on statements. If a statement is

clang/include/clang/Basic/DiagnosticSemaKinds.td

 
 /// Selector for a TagTypeKind value.
 def select_tag_type_kind : TextSubstitution<
   "%select{struct|interface|union|class|enum}0">;
 
 def err_static_data_member_not_allowed_in_anon_struct : Error<
   "static data member %0 not allowed in anonymous "
   "%sub{select_tag_type_kind}1">;
 def ext_static_data_member_in_union : ExtWarn<
   "static data member %0 in union is a C++11 extension">, InGroup<CXX11>;
 def warn_cxx98_compat_static_data_member_in_union : Warning<
   "static data member %0 in union is incompatible with C++98">,
   InGroup<CXX98Compat>, DefaultIgnore;
 def ext_union_member_of_reference_type : ExtWarn<
   "union member %0 has reference type %1, which is a Microsoft extension">,
   InGroup<MicrosoftUnionMemberReference>;
 def err_union_member_of_reference_type : Error<
   "union member %0 has reference type %1">;
 def ext_anonymous_struct_union_qualified : Extension<
   "anonymous %select{struct|union}0 cannot be '%1'">;
 def err_different_return_type_for_overriding_virtual_function : Error<
   "virtual function %0 has a different return type "
   "%diff{($) than the function it overrides (which has return type $)|"
   "than the function it overrides}1,2">;
 def note_overridden_virtual_function : Note<
   "overridden virtual function is here">;
+def err_conflicting_overriding_attributes : Error<
+  "virtual function %0 has different attributes "
+  "%diff{($) than the function it overrides (which has $)|"
+  "than the function it overrides}1,2">;
 def err_conflicting_overriding_cc_attributes : Error<
   "virtual function %0 has different calling convention attributes "
   "%diff{($) than the function it overrides (which has calling convention $)|"
   "than the function it overrides}1,2">;
 def warn_overriding_method_missing_noescape : Warning<
   "parameter of overriding method should be annotated with "
   "__attribute__((noescape))">, InGroup<MissingNoEscape>;
 def note_overridden_marked_noescape : Note<

 def warn_attribute_dll_instantiated_base_class : Warning<
   "propagating dll attribute to %select{already instantiated|explicitly specialized}0 "
   "base class template without dll attribute is not supported">,
   InGroup<DiagGroup<"unsupported-dll-base-class-template">>, DefaultIgnore;
 def err_attribute_dll_ambiguous_default_ctor : Error<
   "'__declspec(dllexport)' cannot be applied to more than one default constructor in %0">;
 def err_attribute_weakref_not_static : Error<
   "weakref declaration must have internal linkage">;
 def err_attribute_weakref_not_global_context : Error<
   "weakref declaration of %0 must be in a global context">;
 def err_attribute_weakref_without_alias : Error<
   "weakref declaration of %0 must also have an alias attribute">;
 def err_alias_not_supported_on_darwin : Error <
   "aliases are not supported on darwin">;
 def warn_attribute_wrong_decl_type_str : Warning<
   "%0%select{ attribute|}1 only applies to %2">, InGroup<IgnoredAttributes>;
 def err_attribute_wrong_decl_type_str : Error<
   warn_attribute_wrong_decl_type_str.Summary>;

 def warn_gnu_inline_cplusplus_without_extern : Warning<
   "'gnu_inline' attribute without 'extern' in C++ treated as externally"
   " available, this changed in Clang 10">,
   InGroup<DiagGroup<"gnu-inline-cpp-without-extern">>;
 def err_attribute_vecreturn_only_vector_member : Error<
   "the vecreturn attribute can only be used on a class or structure with one member, which must be a vector">;
 def err_attribute_vecreturn_only_pod_record : Error<
   "the vecreturn attribute can only be used on a POD (plain old data) class or structure (i.e. no virtual functions)">;
+def err_sme_attr_mismatch : Error<
+  "function declared '%0' was previously declared '%1'"
+  " with different SME function attributes">;
 def err_cconv_change : Error<
   "function declared '%0' here was previously declared "
   "%select{'%2'|without calling convention}1">;
 def warn_cconv_unsupported : Warning<
   "%0 calling convention is not supported %select{"
   // Use CallingConventionIgnoredReason Enum to specify these.
   "for this target"
   "|on variadic function"

clang/include/clang/Sema/Sema.h

public:
   bool ActOnCXXNestedNameSpecifierDecltype(CXXScopeSpec &SS,
                                            const DeclSpec &DS,
                                            SourceLocation ColonColonLoc);
 
   bool IsInvalidUnlessNestedName(Scope *S, CXXScopeSpec &SS,
                                  NestedNameSpecInfo &IdInfo,
                                  bool EnteringContext);
 
+  bool IsInvalidSMECallConversion(QualType FromType, QualType ToType);
+
   /// The parser has parsed a nested-name-specifier
   /// 'template[opt] template-name < template-args >::'.
   ///
   /// \param S The scope in which this nested-name-specifier occurs.
   ///
   /// \param SS The nested-name-specifier, which is both an input
   /// parameter (the nested-name-specifier before this type) and an
   /// output parameter (containing the full nested-name-specifier,

clang/lib/AST/Type.cpp

FunctionProtoType::FunctionProtoType(QualType result, ArrayRef<QualType> params,
   // Fill in the trailing argument array.
   auto *argSlot = getTrailingObjects<QualType>();
   for (unsigned i = 0; i != getNumParams(); ++i) {
     addDependence(params[i]->getDependence() &
                   ~TypeDependence::VariablyModified);
     argSlot[i] = params[i];
   }
 
+  // Propagate the SME ACLE attributes.
+  if (epi.AArch64SMEAttributes != SME_NormalFunction) {
+    auto &ExtraBits = *getTrailingObjects<FunctionTypeExtraBitfields>();
+    ExtraBits.setAArch64SMEAttributes(epi.AArch64SMEAttributes);
+  }
+
   // Fill in the exception type array if present.
   if (getExceptionSpecType() == EST_Dynamic) {
     auto &ExtraBits = *getTrailingObjects<FunctionTypeExtraBitfields>();
     ExtraBits.setNumExceptionType(epi.ExceptionSpec.Exceptions.size());
 
     assert(hasExtraBitfields() && "missing trailing extra bitfields!");
     auto *exnSlot =
         reinterpret_cast<QualType *>(getTrailingObjects<ExceptionType>());
void FunctionProtoType::Profile(llvm::FoldingSetNodeID &ID, QualType Result,
   //
   // The encoding grammar begins:
   //      type type* bool int bool
   // If that final bool is true, then there is a section for the EH spec:
   //      bool type*
   // This is followed by an optional "consumed argument" section of the
   // same length as the first type sequence:
   //      bool*
   // Finally, we have the ext info and trailing return type flag:
   //      int bool
   //
   // There is no ambiguity between the consumed arguments and an empty EH
   // spec because of the leading 'bool' which unambiguously indicates
   // whether the following bool is the EH spec or part of the arguments.
 
   ID.AddPointer(Result.getAsOpaquePtr());
   for (unsigned i = 0; i != NumParams; ++i)
void FunctionProtoType::Profile(llvm::FoldingSetNodeID &ID, QualType Result,
   } else if (epi.ExceptionSpec.Type == EST_Uninstantiated ||
              epi.ExceptionSpec.Type == EST_Unevaluated) {
     ID.AddPointer(epi.ExceptionSpec.SourceDecl->getCanonicalDecl());
   }
   if (epi.ExtParameterInfos) {
     for (unsigned i = 0; i != NumParams; ++i)
       ID.AddInteger(epi.ExtParameterInfos[i].getOpaqueValue());
   }
+  ID.AddInteger(epi.AArch64SMEAttributes);
+
   epi.ExtInfo.Profile(ID);
   ID.AddBoolean(epi.HasTrailingReturn);
 }
 
 void FunctionProtoType::Profile(llvm::FoldingSetNodeID &ID,
                                 const ASTContext &Ctx) {
   Profile(ID, getReturnType(), param_type_begin(), getNumParams(),
           getExtProtoInfo(), Ctx, isCanonicalUnqualified());

clang/lib/AST/TypePrinter.cpp

if (T->isVariadic()) {
     // Do not emit int() if we have a proto, emit 'int(void)'.
     OS << "void";
   }
 
   OS << ')';
 
   FunctionType::ExtInfo Info = T->getExtInfo();
 
+  if ((T->getAArch64SMEAttributes() &
+       FunctionType::SME_PStateSMCompatibleMask) &&
+      !InsideCCAttribute)
+    OS << " __arm_streaming_compatible";
+  if ((T->getAArch64SMEAttributes() & FunctionType::SME_PStateSMEnabledMask) &&
+      !InsideCCAttribute)
+    OS << " __arm_streaming";
+  if ((T->getAArch64SMEAttributes() & FunctionType::SME_PStateZASharedMask) &&
+      !InsideCCAttribute)
+    OS << " __arm_shared_za";
+  if ((T->getAArch64SMEAttributes() &
+       FunctionType::SME_PStateZAPreservedMask) &&
+      !InsideCCAttribute)
+    OS << " __arm_preserves_za";
+
   printFunctionAfter(Info, OS);
 
   if (!T->getMethodQuals().empty())
     OS << " " << T->getMethodQuals().getAsString();
 
   switch (T->getRefQualifier()) {
   case RQ_None:
     break;
if (T->getAttrKind() == attr::AnnotateType) {
     OS << " [[clang::annotate_type(...)]]";
     return;
   }
 
   if (T->getAttrKind() == attr::ArmStreaming) {
     OS << "__arm_streaming";
     return;
   }
+  if (T->getAttrKind() == attr::ArmStreamingCompatible) {
+    OS << "__arm_streaming_compatible";
+    return;
+  }
+  if (T->getAttrKind() == attr::ArmSharedZA) {
+    OS << "__arm_shared_za";
+    return;
+  }
+  if (T->getAttrKind() == attr::ArmPreservesZA) {
+    OS << "__arm_preserves_za";
+    return;
+  }
 
   OS << " __attribute__((";
   switch (T->getAttrKind()) {
 #define TYPE_ATTR(NAME)
 #define DECL_OR_TYPE_ATTR(NAME)
 #define ATTR(NAME) case attr::NAME:
 #include "clang/Basic/AttrList.inc"
     llvm_unreachable("non-type attribute attached to type");
#include "clang/Basic/AttrList.inc"
   case attr::Ptr64:
   case attr::SPtr:
   case attr::UPtr:
   case attr::AddressSpace:
   case attr::CmseNSCall:
   case attr::AnnotateType:
   case attr::WebAssemblyFuncref:
   case attr::ArmStreaming:
+  case attr::ArmStreamingCompatible:
+  case attr::ArmSharedZA:
+  case attr::ArmPreservesZA:
     llvm_unreachable("This attribute should have been handled already");
 
   case attr::NSReturnsRetained:
     OS << "ns_returns_retained";
     break;
 
   // FIXME: When Sema learns to form this AttributedType, avoid printing the
   // attribute again in printFunctionProtoAfter.

clang/lib/CodeGen/CGCall.cpp

static void AddAttributesFromFunctionProtoType(ASTContext &Ctx,
                                                llvm::AttrBuilder &FuncAttrs,
                                                const FunctionProtoType *FPT) {
   if (!FPT)
     return;
 
   if (!isUnresolvedExceptionSpec(FPT->getExceptionSpecType()) &&
       FPT->isNothrow())
     FuncAttrs.addAttribute(llvm::Attribute::NoUnwind);
+
+  if (FPT->getAArch64SMEAttributes() & FunctionType::SME_PStateSMEnabledMask)
+    FuncAttrs.addAttribute("aarch64_pstate_sm_enabled");
+  if (FPT->getAArch64SMEAttributes() & FunctionType::SME_PStateSMCompatibleMask)
+    FuncAttrs.addAttribute("aarch64_pstate_sm_compatible");
+  if (FPT->getAArch64SMEAttributes() & FunctionType::SME_PStateZASharedMask)
+    FuncAttrs.addAttribute("aarch64_pstate_za_shared");
+  if (FPT->getAArch64SMEAttributes() & FunctionType::SME_PStateZAPreservedMask)
+    FuncAttrs.addAttribute("aarch64_pstate_za_preserved");
 }
 
 static void AddAttributesFromAssumes(llvm::AttrBuilder &FuncAttrs,
                                      const Decl *Callee) {
   if (!Callee)
     return;
 
   SmallVector<StringRef, 4> Attrs;
if (TargetDecl->hasAttr<OpenCLKernelAttr>()) {
         // '-cl-uniform-work-group-size' compile option gets a hint
         // to the compiler that the global work-size be a multiple of
         // the work-group size specified to clEnqueueNDRangeKernel
         // (i.e. work groups are uniform).
         FuncAttrs.addAttribute("uniform-work-group-size",
                                llvm::toStringRef(CodeGenOpts.UniformWGSize));
       }
     }
+
+    if (TargetDecl->hasAttr<ArmLocallyStreamingAttr>())
+      FuncAttrs.addAttribute("aarch64_pstate_sm_body");
+
+    if (TargetDecl->hasAttr<ArmNewZAAttr>())
+      FuncAttrs.addAttribute("aarch64_pstate_za_new");
   }
 
   // Attach "no-builtins" attributes to:
   // * call sites: both `nobuiltin` and "no-builtins" or "no-builtin-<name>".
   // * definitions: "no-builtins" or "no-builtin-<name>" only.
   // The attributes can come from:
   // * LangOpts: -ffreestanding, -fno-builtin, -fno-builtin-<name>
   // * FunctionDecl attributes: __attribute__((no_builtin(...)))
   addNoBuiltinAttributes(FuncAttrs, getLangOpts(), NBA);
 
   // Collect function IR attributes based on global settiings.
   getDefaultFunctionAttributes(Name, HasOptnone, AttrOnCallSite, FuncAttrs);
 
   // Override some default IR attributes based on declaration-specific
   // information.
   if (TargetDecl) {
     if (TargetDecl->hasAttr<NoSpeculativeLoadHardeningAttr>())
       FuncAttrs.removeAttribute(llvm::Attribute::SpeculativeLoadHardening);
     if (TargetDecl->hasAttr<SpeculativeLoadHardeningAttr>())
       FuncAttrs.addAttribute(llvm::Attribute::SpeculativeLoadHardening);

clang/lib/CodeGen/CodeGenModule.cpp

if (!D) {
     if (!F->hasFnAttribute(llvm::Attribute::AlwaysInline) &&
         CodeGenOpts.getInlining() == CodeGenOptions::OnlyAlwaysInlining)
       B.addAttribute(llvm::Attribute::NoInline);
 
     F->addFnAttrs(B);
     return;
   }
 
+  // We only need to handle the 'arm_locally_streaming' attribute as a
+  // special case here (as opposed to e.g. 'arm_streaming'), because it
+  // is not set from the prototype, but rather from the definition.
+  // The same holds for 'arm_new_za'.
+  if (D->hasAttr<ArmLocallyStreamingAttr>())
+    B.addAttribute("aarch64_pstate_sm_body");
+
+  if (D->hasAttr<ArmNewZAAttr>())
+    B.addAttribute("aarch64_pstate_za_new");
+
   // Track whether we need to add the optnone LLVM attribute,
   // starting with the default for this optimization level.
   bool ShouldAddOptNone =
       !CodeGenOpts.DisableO0ImplyOptNone && CodeGenOpts.OptimizationLevel == 0;
   // We can't add optnone in the following cases, it won't pass the verifier.
   ShouldAddOptNone &= !D->hasAttr<MinSizeAttr>();
   ShouldAddOptNone &= !D->hasAttr<AlwaysInlineAttr>();
 

clang/lib/Sema/SemaDecl.cpp

if (OldOvl != New->hasAttr<OverloadableAttr>() && !Old->isImplicit()) {
 
       if (OldOvl)
         New->addAttr(OverloadableAttr::CreateImplicit(Context));
       else
         New->dropAttr<OverloadableAttr>();
     }
   }
 
+  // It is not allowed to redeclare an SME function with different SME
+  // attributes.
+  if (IsInvalidSMECallConversion(Old->getType(), New->getType())) {
+    Diag(New->getLocation(), diag::err_sme_attr_mismatch)
+        << New->getType() << Old->getType();
+    Diag(OldLocation, diag::note_previous_declaration);
+    return true;
+  }
+
   // If a function is first declared with a calling convention, but is later
   // declared or defined without one, all following decls assume the calling
   // convention of the first.
   //
   // It's OK if a function is first declared without a calling convention,
   // but is later declared or defined with the default calling convention.
   //
   // To test if either decl has an explicit calling convention, we look for

clang/lib/Sema/SemaDeclAttr.cpp

 /// declaration. Returns true if diagnosed.
 template <typename AttrTy>
 static bool checkAttrMutualExclusion(Sema &S, Decl *D, const ParsedAttr &AL) {
   if (const auto *A = D->getAttr<AttrTy>()) {
     S.Diag(AL.getLoc(), diag::err_attributes_are_not_compatible)
         << AL << A
         << (AL.isRegularKeywordAttribute() || A->isRegularKeywordAttribute());
     S.Diag(A->getLocation(), diag::note_conflicting_attribute);
     return true;
   }
   return false;
 }
 
 template <typename AttrTy>
 static bool checkAttrMutualExclusion(Sema &S, Decl *D, const Attr &AL) {
   if (const auto *A = D->getAttr<AttrTy>()) {
     S.Diag(AL.getLocation(), diag::err_attributes_are_not_compatible)
case ParsedAttr::AT_VectorCall:
     CC = CC_X86VectorCall;
     break;
   case ParsedAttr::AT_AArch64VectorPcs:
     CC = CC_AArch64VectorCall;
     break;
   case ParsedAttr::AT_AArch64SVEPcs:
     CC = CC_AArch64SVEPCS;
     break;
-  case ParsedAttr::AT_ArmStreaming:
-    CC = CC_C; // FIXME: placeholder until real SME support is added.
-    break;
   case ParsedAttr::AT_AMDGPUKernelCall:
     CC = CC_AMDGPUKernelCall;
     break;
   case ParsedAttr::AT_RegCall:
     CC = CC_X86RegCall;
     break;
   case ParsedAttr::AT_MSABI:
     CC = Context.getTargetInfo().getTriple().isOSWindows() ? CC_C :
static void handleDestroyAttr(Sema &S, Decl *D, const ParsedAttr &A) {
 
   if (A.getKind() == ParsedAttr::AT_AlwaysDestroy)
     handleSimpleAttribute<AlwaysDestroyAttr>(S, D, A);
   else
     handleSimpleAttribute<NoDestroyAttr>(S, D, A);
 }
 
 static void handleUninitializedAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   assert(cast<VarDecl>(D)->getStorageDuration() == SD_Automatic &&
          "uninitialized is only valid on automatic duration variables");
   D->addAttr(::new (S.Context) UninitializedAttr(S.Context, AL));
 }
 
 static bool tryMakeVariablePseudoStrong(Sema &S, VarDecl *VD,
                                         bool DiagnoseFailure) {
   QualType Ty = VD->getType();
   if (!Ty->isObjCRetainableType()) {
     if (DiagnoseFailure) {
       S.Diag(VD->getBeginLoc(), diag::warn_ignored_objc_externally_retained)
           << 0;
     }
     return false;
   }
 
   Qualifiers::ObjCLifetime LifetimeQual = Ty.getQualifiers().getObjCLifetime();
 
   // Sema::inferObjCARCLifetime must run after processing decl attributes
   // (because __block lowers to an attribute), so if the lifetime hasn't been
   // explicitly specified, infer it locally now.
   if (LifetimeQual == Qualifiers::OCL_None)
     LifetimeQual = Ty->getObjCARCImplicitLifetime();
 
   // The attributes only really makes sense for __strong variables; ignore any
   // attempts to annotate a parameter with any other lifetime qualifier.
   if (LifetimeQual != Qualifiers::OCL_Strong) {
     if (DiagnoseFailure) {
       S.Diag(VD->getBeginLoc(), diag::warn_ignored_objc_externally_retained)
           << 1;
ProcessDeclAttribute(Sema &S, Scope *scope, Decl *D, const ParsedAttr &AL,
   case ParsedAttr::AT_MSAllocator:
     handleMSAllocatorAttr(S, D, AL);
     break;
 
   case ParsedAttr::AT_ArmBuiltinAlias:
     handleArmBuiltinAliasAttr(S, D, AL);
     break;
 
+  case ParsedAttr::AT_ArmLocallyStreaming:
+    handleSimpleAttribute<ArmLocallyStreamingAttr>(S, D, AL);
+    break;
+
+  case ParsedAttr::AT_ArmNewZA:
+    if (auto *FPT = dyn_cast<FunctionProtoType>(D->getFunctionType())) {
+      if (FPT->getAArch64SMEAttributes() &
+          FunctionType::SME_PStateZASharedMask) {
+        S.Diag(AL.getLoc(), diag::err_attributes_are_not_compatible)
+            << AL << "'__arm_shared_za'" << true;
+        AL.setInvalid();
+      }
+      if (FPT->getAArch64SMEAttributes() &
+          FunctionType::SME_PStateZAPreservedMask) {
+        S.Diag(AL.getLoc(), diag::err_attributes_are_not_compatible)
+            << AL << "'__arm_preserves_za'" << true;
+        AL.setInvalid();
+      }
+      if (AL.isInvalid())
+        return;
+    }
+    handleSimpleAttribute<ArmNewZAAttr>(S, D, AL);
+    break;
   case ParsedAttr::AT_AcquireHandle:
     handleAcquireHandleAttr(S, D, AL);
     break;
 
   case ParsedAttr::AT_ReleaseHandle:
     handleHandleAttr<ReleaseHandleAttr>(S, D, AL);
     break;
 

clang/lib/Sema/SemaDeclCXX.cpp

for (unsigned I = 0, E = OldFT->getNumParams(); I != E; ++I)
           !NewFT->getExtParameterInfo(I).isNoEscape()) {
         Diag(New->getParamDecl(I)->getLocation(),
              diag::warn_overriding_method_missing_noescape);
         Diag(Old->getParamDecl(I)->getLocation(),
              diag::note_overridden_marked_noescape);
       }
   }
 
+  // SME attributes must match when overriding a function declaration.
+  if (IsInvalidSMECallConversion(Old->getType(), New->getType())) {
+    Diag(New->getLocation(), diag::err_conflicting_overriding_attributes)
+        << New << New->getType() << Old->getType();
+    Diag(Old->getLocation(), diag::note_overridden_virtual_function);
+    return true;
+  }
+
   // Virtual overrides must have the same code_seg.
   const auto *OldCSA = Old->getAttr<CodeSegAttr>();
   const auto *NewCSA = New->getAttr<CodeSegAttr>();
   if ((NewCSA || OldCSA) &&
       (!OldCSA || !NewCSA || NewCSA->getName() != OldCSA->getName())) {
     Diag(New->getLocation(), diag::err_mismatched_code_seg_override);
     Diag(Old->getLocation(), diag::note_previous_declaration);
     return true;

clang/lib/Sema/SemaExpr.cpp

return new (Context)
         ConditionalOperator(Cond.get(), QuestionLoc, LHS.get(), ColonLoc,
                             RHS.get(), result, VK, OK);
 
   return new (Context) BinaryConditionalOperator(
       commonExpr, opaqueValue, Cond.get(), LHS.get(), RHS.get(), QuestionLoc,
       ColonLoc, result, VK, OK);
 }
 
+// Check that the SME attributes for PSTATE.ZA and PSTATE.SM are compatible.
+bool Sema::IsInvalidSMECallConversion(QualType FromType, QualType ToType) {
+  unsigned FromAttributes = 0, ToAttributes = 0;
+  if (const auto *FromFn =
+          dyn_cast<FunctionProtoType>(Context.getCanonicalType(FromType)))
+    FromAttributes =
+        FromFn->getAArch64SMEAttributes() & FunctionType::SME_AttributeMask;
+  if (const auto *ToFn =
+          dyn_cast<FunctionProtoType>(Context.getCanonicalType(ToType)))
+    ToAttributes =
+        ToFn->getAArch64SMEAttributes() & FunctionType::SME_AttributeMask;
+
+  if (FromAttributes == ToAttributes)
+    return false;
+
+  // Make an exception for preserves_za, which can be dropped because it's
+  // only a hint.
+  unsigned Changed = FromAttributes ^ ToAttributes;
+  bool DropsPreservesZA =
+      Changed == FunctionType::SME_PStateZAPreservedMask &&
+      (ToAttributes & FunctionType::SME_PStateZAPreservedMask);
+  return !DropsPreservesZA;
+}
+
 // Check if we have a conversion between incompatible cmse function pointer
 // types, that is, a conversion between a function pointer with the
 // cmse_nonsecure_call attribute and one without.
 static bool IsInvalidCmseNSCallConversion(Sema &S, QualType FromType,
                                           QualType ToType) {
   if (const auto *ToFn =
           dyn_cast<FunctionType>(S.Context.getCanonicalType(ToType))) {
     if (const auto *FromFn =
if (RHSType->isFunctionPointerType() && LHSType->isFunctionPointerType())
       return Sema::IncompatibleFunctionPointer;
     return Sema::IncompatiblePointer;
   }
   if (!S.getLangOpts().CPlusPlus &&
       S.IsFunctionConversion(ltrans, rtrans, ltrans))
     return Sema::IncompatibleFunctionPointer;
   if (IsInvalidCmseNSCallConversion(S, ltrans, rtrans))
     return Sema::IncompatibleFunctionPointer;
+  if (S.IsInvalidSMECallConversion(ltrans, rtrans))
+    return Sema::IncompatibleFunctionPointer;
   return ConvTy;
 }
 
 /// checkBlockPointerTypesForAssignment - This routine determines whether two
 /// block pointer types are compatible or whether a block and normal pointer
 /// are compatible. It is more restrict than comparing two function pointer
 // types.
 static Sema::AssignConvertType

clang/lib/Sema/SemaOverload.cpp

bool Sema::IsFunctionConversion(QualType FromType, QualType ToType,
   bool Changed = false;
 
   // Drop 'noreturn' if not present in target type.
   if (FromEInfo.getNoReturn() && !ToEInfo.getNoReturn()) {
     FromFn = Context.adjustFunctionType(FromFn, FromEInfo.withNoReturn(false));
     Changed = true;
   }
 
+  // Drop the 'arm_preserves_za' if not present in the target type (we can do
+  // that because it is merely a hint).
+  if (const auto *FromFPT = dyn_cast<FunctionProtoType>(FromFn)) {
+    FunctionProtoType::ExtProtoInfo ExtInfo = FromFPT->getExtProtoInfo();
+    if (ExtInfo.AArch64SMEAttributes &
+        FunctionType::SME_PStateZAPreservedMask) {
+      unsigned ToFlags = 0;
+      if (const auto *ToFPT = dyn_cast<FunctionProtoType>(ToFn))
+        ToFlags = ToFPT->getExtProtoInfo().AArch64SMEAttributes;
+      if (!(ToFlags & FunctionType::SME_PStateZAPreservedMask)) {
+        ExtInfo.setArmSMEAttribute(FunctionType::SME_PStateZAPreservedMask,
+                                   false);
+        QualType QT = Context.getFunctionType(
+            FromFPT->getReturnType(), FromFPT->getParamTypes(), ExtInfo);
+        FromFn = QT->getAs<FunctionType>();
+        Changed = true;
+      }
+    }
+  }
+
   // Drop 'noexcept' if not present in target type.
   if (const auto *FromFPT = dyn_cast<FunctionProtoType>(FromFn)) {
     const auto *ToFPT = cast<FunctionProtoType>(ToFn);
     if (FromFPT->isNothrow() && !ToFPT->isNothrow()) {
       FromFn = cast<FunctionType>(
           Context.getFunctionTypeWithExceptionSpec(QualType(FromFPT, 0),
                                                    EST_None)
                  .getTypePtr());

clang/lib/Sema/SemaType.cpp

#define CALLING_CONV_ATTRS_CASELIST                                            \
   case ParsedAttr::AT_ThisCall:                                                \
   case ParsedAttr::AT_RegCall:                                                 \
   case ParsedAttr::AT_Pascal:                                                  \
   case ParsedAttr::AT_SwiftCall:                                               \
   case ParsedAttr::AT_SwiftAsyncCall:                                          \
   case ParsedAttr::AT_VectorCall:                                              \
   case ParsedAttr::AT_AArch64VectorPcs:                                        \
   case ParsedAttr::AT_AArch64SVEPcs:                                           \
-  case ParsedAttr::AT_ArmStreaming:                                            \
   case ParsedAttr::AT_AMDGPUKernelCall:                                        \
   case ParsedAttr::AT_MSABI:                                                   \
   case ParsedAttr::AT_SysVABI:                                                 \
   case ParsedAttr::AT_Pcs:                                                     \
   case ParsedAttr::AT_IntelOclBicc:                                            \
   case ParsedAttr::AT_PreserveMost:                                            \
   case ParsedAttr::AT_PreserveAll
 
 // Function type attributes.
 #define FUNCTION_TYPE_ATTRS_CASELIST                                           \
   case ParsedAttr::AT_NSReturnsRetained:                                       \
   case ParsedAttr::AT_NoReturn:                                                \
   case ParsedAttr::AT_Regparm:                                                 \
   case ParsedAttr::AT_CmseNSCall:                                              \
+  case ParsedAttr::AT_ArmStreaming:                                            \
+  case ParsedAttr::AT_ArmStreamingCompatible:                                  \
+  case ParsedAttr::AT_ArmSharedZA:                                             \
+  case ParsedAttr::AT_ArmPreservesZA:                                          \
   case ParsedAttr::AT_AnyX86NoCallerSavedRegisters:                            \
   case ParsedAttr::AT_AnyX86NoCfCheck:                                         \
     CALLING_CONV_ATTRS_CASELIST
 
 // Microsoft-specific type qualifiers.
 #define MS_TYPE_ATTRS_CASELIST                                                 \
   case ParsedAttr::AT_Ptr32:                                                   \
   case ParsedAttr::AT_Ptr64:                                                   \
static Attr *getCCTypeAttr(ASTContext &Ctx, ParsedAttr &Attr) {
   case ParsedAttr::AT_PreserveMost:
     return createSimpleAttr<PreserveMostAttr>(Ctx, Attr);
   case ParsedAttr::AT_PreserveAll:
     return createSimpleAttr<PreserveAllAttr>(Ctx, Attr);
   }
   llvm_unreachable("unexpected attribute kind!");
 }
 
+static bool checkMutualExclusion(TypeProcessingState &state,
+                                 const FunctionProtoType::ExtProtoInfo &EPI,
+                                 ParsedAttr &Attr,
+                                 AttributeCommonInfo::Kind OtherKind) {
+  auto OtherAttr = std::find_if(
+      state.getCurrentAttributes().begin(), state.getCurrentAttributes().end(),
+      [OtherKind](const ParsedAttr &A) { return A.getKind() == OtherKind; });
+  if (OtherAttr == state.getCurrentAttributes().end() || OtherAttr->isInvalid())
+    return false;
+
+  Sema &S = state.getSema();
+  S.Diag(Attr.getLoc(), diag::err_attributes_are_not_compatible)
+      << *OtherAttr << Attr
+      << (OtherAttr->isRegularKeywordAttribute() ||
+          Attr.isRegularKeywordAttribute());
+  S.Diag(OtherAttr->getLoc(), diag::note_conflicting_attribute);
+  Attr.setInvalid();
+  return true;
+}
+
 /// Process an individual function attribute.  Returns true to
 /// indicate that the attribute was handled, false if it wasn't.
 static bool handleFunctionTypeAttr(TypeProcessingState &state, ParsedAttr &attr,
                                    QualType &type) {
   Sema &S = state.getSema();
 
   FunctionTypeUnwrapper unwrapped(S, type);
 
if (attr.getKind() == ParsedAttr::AT_Regparm) {
     }
 
     FunctionType::ExtInfo EI =
       unwrapped.get()->getExtInfo().withRegParm(value);
     type = unwrapped.wrap(S, S.Context.adjustFunctionType(unwrapped.get(), EI));
     return true;
   }
 
+  if (attr.getKind() == ParsedAttr::AT_ArmStreaming ||
+      attr.getKind() == ParsedAttr::AT_ArmStreamingCompatible ||
+      attr.getKind() == ParsedAttr::AT_ArmSharedZA ||
+      attr.getKind() == ParsedAttr::AT_ArmPreservesZA){
+    if (S.CheckAttrTarget(attr) || S.CheckAttrNoArgs(attr))
+      return true;
+
+    if (!unwrapped.isFunctionType())
+      return false;
+
+    const FunctionProtoType *FnTy = unwrapped.get()->getAs<FunctionProtoType>();
+    if (!FnTy) {
+      // SME ACLE attributes are not supported on K&R-style unprototyped C
+      // functions.
+      S.Diag(attr.getLoc(), diag::warn_attribute_wrong_decl_type) <<
+        attr << attr.isRegularKeywordAttribute() << ExpectedFunctionWithProtoType;
+      attr.setInvalid();
+      return false;
+    }
+
+    FunctionProtoType::ExtProtoInfo EPI = FnTy->getExtProtoInfo();
+    switch (attr.getKind()) {
+    case ParsedAttr::AT_ArmStreaming:
+      if (checkMutualExclusion(state, EPI, attr,
+                               ParsedAttr::AT_ArmStreamingCompatible))
+        return true;
+      EPI.setArmSMEAttribute(FunctionType::SME_PStateSMEnabledMask);
+      break;
+    case ParsedAttr::AT_ArmStreamingCompatible:
+      if (checkMutualExclusion(state, EPI, attr, ParsedAttr::AT_ArmStreaming))
+        return true;
+      EPI.setArmSMEAttribute(FunctionType::SME_PStateSMCompatibleMask);
+      break;
+    case ParsedAttr::AT_ArmSharedZA:
+      EPI.setArmSMEAttribute(FunctionType::SME_PStateZASharedMask);
+      break;
+    case ParsedAttr::AT_ArmPreservesZA:
+      EPI.setArmSMEAttribute(FunctionType::SME_PStateZAPreservedMask);
+      break;
+    default:
+      llvm_unreachable("Unsupported attribute");
+    }
+
+    QualType newtype = S.Context.getFunctionType(FnTy->getReturnType(),
+                                                 FnTy->getParamTypes(), EPI);
+    type = unwrapped.wrap(S, newtype->getAs<FunctionType>());
+    return true;
+  }
+
   if (attr.getKind() == ParsedAttr::AT_NoThrow) {
     // Delay if this is not a function type.
     if (!unwrapped.isFunctionType())
       return false;
 
     if (S.CheckAttrNoArgs(attr)) {
       attr.setInvalid();
       return true;

clang/test/AST/ast-dump-sme-attributes.cpp

+// Test without serialization:
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -std=c++2a -ast-dump -ast-dump-filter Foo %s | FileCheck -strict-whitespace %s
+
+// Test with serialization:
+// RUN: %clang_cc1 -std=c++20 -triple aarch64 -target-feature +sme -emit-pch -o %t %s
+// RUN: %clang_cc1 -x c++ -std=c++20 -triple aarch64 -target-feature +sme -include-pch %t -ast-dump-all -ast-dump-filter Foo /dev/null \
+// RUN: | sed -e "s/ <undeserialized declarations>//" -e "s/ imported//" \
+// RUN: | FileCheck --strict-whitespace %s
+
+struct Foo {
+// CHECK:      |-CXXRecordDecl {{.*}} implicit struct Foo
+// CHECK-NEXT: |-CXXMethodDecl {{.*}} f_streaming 'void () __arm_streaming'
+// CHECK-NEXT: |-CXXMethodDecl {{.*}} f_streaming_compatible 'void () __arm_streaming_compatible'
+// CHECK-NEXT: |-CXXMethodDecl {{.*}} f_locally_streaming 'void ()'
+// CHECK-NEXT: | `-ArmLocallyStreamingAttr
+// CHECK-NEXT: |-CXXMethodDecl {{.*}} f_shared_za 'void () __arm_shared_za'
+// CHECK-NEXT: |-CXXMethodDecl {{.*}} f_new_za 'void ()'
+// CHECK-NEXT: | `-ArmNewZAAttr
+// CHECK-NEXT: |-CXXMethodDecl {{.*}} f_preserves_za 'void () __arm_preserves_za'
+  void f_streaming() __arm_streaming;
+  void f_streaming_compatible() __arm_streaming_compatible;
+  __arm_locally_streaming void f_locally_streaming();
+  void f_shared_za() __arm_shared_za;
+  __arm_new_za void f_new_za();
+  void f_preserves_za() __arm_preserves_za;
+
+
+// CHECK:      |-CXXMethodDecl {{.*}} test_lambda 'int (int)' implicit-inline
+// CHECK:         `-CompoundStmt
+// CHECK-NEXT:     |-DeclStmt
+// CHECK-NEXT:     | `-VarDecl
+// CHECK-NEXT:     |   `-LambdaExpr
+// CHECK-NEXT:     |     |-CXXRecordDecl
+// CHECK:          |     | |-CXXMethodDecl {{.*}} used constexpr operator() 'int (int) __arm_streaming const' inline
+// CHECK:          |     | |-CXXConversionDecl {{.*}} implicit constexpr operator int (*)(int) __arm_streaming 'int (*() const noexcept)(int) __arm_streaming' inline
+// CHECK:          |     | |-CXXMethodDecl {{.*}} implicit __invoke 'int (int) __arm_streaming' static inline
+// CHECK:          `-ReturnStmt
+// CHECK:            `-CXXOperatorCallExpr
+// CHECK-NEXT:         |-ImplicitCastExpr {{.*}} 'int (*)(int) __arm_streaming const' <FunctionToPointerDecay>
+// CHECK-NEXT:         | `-DeclRefExpr {{.*}} 'int (int) __arm_streaming const' lvalue CXXMethod {{.*}} 'operator()' 'int (int) __arm_streaming const'
+  int test_lambda(int x) {
+    auto F = [](int x) __arm_streaming { return x; };
+    return F(x);
+  }
+
+// CHECK: |-TypedefDecl {{.*}} referenced s_ptrty 'void (*)(int, int) __arm_streaming'
+// CHECK-NEXT: | `-PointerType {{.*}} 'void (*)(int, int) __arm_streaming'
+// CHECK-NEXT: |   `-ParenType {{.*}} 'void (int, int) __arm_streaming' sugar
+// CHECK-NEXT: |     `-FunctionProtoType {{.*}} 'void (int, int) __arm_streaming' cdecl
+  typedef void (*s_ptrty) (int, int) __arm_streaming;
+
+// CHECK:      `-CXXMethodDecl {{.*}} test_streaming_ptrty 'void (s_ptrty, int, int)' implicit-inline
+// CHECK-NEXT:   |-ParmVarDecl {{.*}} used f 's_ptrty':'void (*)(int, int) __arm_streaming'
+// CHECK-NEXT:   |-ParmVarDecl {{.*}} used x 'int'
+// CHECK-NEXT:   |-ParmVarDecl {{.*}} used y 'int'
+// CHECK:        `-CompoundStmt
+// CHECK-NEXT:     `-ReturnStmt
+// CHECK-NEXT:       `-CallExpr
+// CHECK-NEXT:         |-ImplicitCastExpr {{.*}} 's_ptrty':'void (*)(int, int) __arm_streaming' <LValueToRValue>
+// CHECK-NEXT:         | `-DeclRefExpr {{.*}} 's_ptrty':'void (*)(int, int) __arm_streaming' lvalue ParmVar {{.*}} 'f' 's_ptrty':'void (*)(int, int) __arm_streaming'
+// CHECK-NEXT:         |-ImplicitCastExpr {{.*}} 'int' <LValueToRValue>
+// CHECK-NEXT:         | `-DeclRefExpr {{.*}} 'int' lvalue ParmVar {{.*}} 'x' 'int'
+// CHECK-NEXT:         `-ImplicitCastExpr {{.*}} 'int' <LValueToRValue>
+// CHECK-NEXT:           `-DeclRefExpr {{.*}} 'int' lvalue ParmVar {{.*}} 'y' 'int'
+  void test_streaming_ptrty(s_ptrty f, int x, int y) { return f(x, y); };
+};

clang/test/CodeGen/aarch64-sme-intrinsics/aarch64-sme-attrs.cpp

+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sme \
+// RUN:   -S -O0 -Werror -emit-llvm -o - %s | FileCheck %s
+
+extern "C" {
+
+extern int normal_callee();
+
+// == FUNCTION DECLARATIONS ==
+
+int streaming_decl(void) __arm_streaming;
+int streaming_compatible_decl(void) __arm_streaming_compatible;
+int shared_za_decl(void) __arm_shared_za;
+int preserves_za_decl(void) __arm_preserves_za;
+int private_za_decl(void);
+
+// == FUNCTION DEFINITIONS ==
+
+// CHECK-LABEL: @streaming_caller()
+// CHECK-SAME: #[[SM_ENABLED:[0-9]+]]
+// CHECK: call i32 @normal_callee()
+//
+ int streaming_caller() __arm_streaming {
+  return normal_callee();
+}
+
+// CHECK: declare i32 @normal_callee() #[[NORMAL_DECL:[0-9]+]]
+
+
+// CHECK-LABEL: @streaming_callee()
+// CHECK-SAME: #[[SM_ENABLED]]
+// CHECK: call i32 @streaming_decl() #[[SM_ENABLED_CALL:[0-9]+]]
+//
+ int streaming_callee() __arm_streaming {
+  return streaming_decl();
+}
+
+// CHECK: declare i32 @streaming_decl() #[[SM_ENABLED_DECL:[0-9]+]]
+
+// CHECK-LABEL: @streaming_compatible_caller()
+// CHECK-SAME: #[[SM_COMPATIBLE:[0-9]+]]
+// CHECK: call i32 @normal_callee()
+//
+ int streaming_compatible_caller() __arm_streaming_compatible {
+  return normal_callee();
+}
+
+// CHECK-LABEL: @streaming_compatible_callee()
+// CHECK-SAME: #[[SM_COMPATIBLE]]
+// CHECK: call i32 @streaming_compatible_decl() #[[SM_COMPATIBLE_CALL:[0-9]+]]
+//
+ int streaming_compatible_callee() __arm_streaming_compatible {
+  return streaming_compatible_decl();
+}
+
+// CHECK: declare i32 @streaming_compatible_decl() #[[SM_COMPATIBLE_DECL:[0-9]+]]
+
+// CHECK-LABEL: @locally_streaming_caller()
+// CHECK-SAME: #[[SM_BODY:[0-9]+]]
+// CHECK: call i32 @normal_callee()
+//
+__arm_locally_streaming int locally_streaming_caller() {
+  return normal_callee();
+}
+
+// CHECK-LABEL: @locally_streaming_callee()
+// CHECK-SAME: #[[SM_BODY]]
+// CHECK: call i32 @locally_streaming_caller() #[[SM_BODY_CALL:[0-9]+]]
+//
+__arm_locally_streaming int locally_streaming_callee() {
+  return locally_streaming_caller();
+}
+
+
+// CHECK-LABEL: @shared_za_caller()
+// CHECK-SAME: #[[ZA_SHARED:[0-9]+]]
+// CHECK: call i32 @normal_callee()
+//
+ int shared_za_caller() __arm_shared_za {
+  return normal_callee();
+}
+
+// CHECK-LABEL: @shared_za_callee()
+// CHECK-SAME: #[[ZA_SHARED]]
+// CHECK: call i32 @shared_za_decl() #[[ZA_SHARED_CALL:[0-9]+]]
+//
+ int shared_za_callee() __arm_shared_za {
+  return shared_za_decl();
+}
+
+// CHECK: declare i32 @shared_za_decl() #[[ZA_SHARED_DECL:[0-9]+]]
+
+
+// CHECK-LABEL: @preserves_za_caller()
+// CHECK-SAME: #[[ZA_PRESERVED:[0-9]+]]
+// CHECK: call i32 @normal_callee()
+//
+ int preserves_za_caller() __arm_preserves_za {
+  return normal_callee();
+}
+
+// CHECK-LABEL: @preserves_za_callee()
+// CHECK-SAME: #[[ZA_PRESERVED]]
+// CHECK: call i32 @preserves_za_decl() #[[ZA_PRESERVED_CALL:[0-9]+]]
+//
+ int preserves_za_callee() __arm_preserves_za {
+  return preserves_za_decl();
+}
+
+// CHECK: declare i32 @preserves_za_decl() #[[ZA_PRESERVED_DECL:[0-9]+]]
+
+
+// CHECK-LABEL: @new_za_caller()
+// CHECK-SAME: #[[ZA_NEW:[0-9]+]]
+// CHECK: call i32 @normal_callee()
+//
+__arm_new_za int new_za_caller() {
+  return normal_callee();
+}
+
+// CHECK-LABEL: @new_za_callee()
+// CHECK-SAME: #[[ZA_NEW]]
+// CHECK: call i32 @private_za_decl()
+//
+__arm_new_za int new_za_callee() {
+  return private_za_decl();
+}
+
+// CHECK: declare i32 @private_za_decl()
+
+
+// Ensure that the attributes are correctly propagated to function types
+// and also to callsites.
+typedef void (*s_ptrty) (int, int) __arm_streaming;
+typedef void (*sc_ptrty) (int, int) __arm_streaming_compatible;
+typedef void (*sz_ptrty) (int, int) __arm_shared_za;
+typedef void (*pz_ptrty) (int, int) __arm_preserves_za;
+
+// CHECK-LABEL: @test_streaming_ptrty(
+// CHECK-SAME: #[[NORMAL_DEF:[0-9]+]]
+// CHECK: call void [[F:%.*]](i32 noundef [[X:%.*]], i32 noundef [[Y:%.*]]) #[[SM_ENABLED_CALL]]
+//
+void test_streaming_ptrty(s_ptrty f, int x, int y) { return f(x, y); }
+// CHECK-LABEL: @test_streaming_compatible_ptrty(
+// CHECK-SAME: #[[NORMAL_DEF]]
+// CHECK: call void [[F:%.*]](i32 noundef [[X:%.*]], i32 noundef [[Y:%.*]]) #[[SM_COMPATIBLE_CALL]]
+//
+void test_streaming_compatible_ptrty(sc_ptrty f, int x, int y) { return f(x, y); }
+// CHECK-LABEL: @test_shared_za(
+// CHECK-SAME: #[[ZA_SHARED]]
+// CHECK: call void [[F:%.*]](i32 noundef [[X:%.*]], i32 noundef [[Y:%.*]]) #[[ZA_SHARED_CALL]]
+//
+void  test_shared_za(sz_ptrty f, int x, int y) __arm_shared_za { return f(x, y); }
+// CHECK-LABEL: @test_preserved_za(
+// CHECK-SAME: #[[ZA_SHARED]]
+// CHECK: call void [[F:%.*]](i32 noundef [[X:%.*]], i32 noundef [[Y:%.*]]) #[[ZA_PRESERVED_CALL]]
+//
+void  test_preserved_za(pz_ptrty f, int x, int y) __arm_shared_za { return f(x, y); }
+
+// CHECK-LABEL: @test_indirect_streaming_ptrty(
+// CHECK-SAME: #[[NORMAL_DEF:[0-9]+]]
+// CHECK: call void [[F:%.*]](i32 noundef [[X:%.*]], i32 noundef [[Y:%.*]]) #[[SM_ENABLED_CALL]]
+//
+typedef s_ptrty **indirect_s_ptrty;
+void test_indirect_streaming_ptrty(indirect_s_ptrty fptr, int x, int y) { return (**fptr)(x, y); }
+} // extern "C"
+
+//
+// Test that having the attribute in different places (on declaration and on type)
+// both results in the attribute being applied to the type.
+//
+
+// CHECK-LABEL: @_Z24test_same_type_streamingv(
+// CHECK:   call void @_Z10streaming1v() #[[SM_ENABLED_CALL]]
+// CHECK:   call void @_Z10streaming2v() #[[SM_ENABLED_CALL]]
+// CHECK:   call void @_Z20same_type_streaming1v() #[[SM_ENABLED_CALL]]
+// CHECK:   call void @_Z20same_type_streaming2v() #[[SM_ENABLED_CALL]]
+// CHECK:   ret void
+// CHECK: }
+// CHECK: declare void @_Z10streaming1v() #[[SM_ENABLED_DECL]]
+// CHECK: declare void @_Z10streaming2v() #[[SM_ENABLED_DECL]]
+// CHECK: declare void @_Z20same_type_streaming1v() #[[SM_ENABLED_DECL]]
+// CHECK: declare void @_Z20same_type_streaming2v() #[[SM_ENABLED_DECL]]
+void streaming1(void) __arm_streaming;
+void streaming2() __arm_streaming;
+decltype(streaming1) same_type_streaming1;
+decltype(streaming2) same_type_streaming2;
+void test_same_type_streaming() {
+  streaming1();
+  streaming2();
+  same_type_streaming1();
+  same_type_streaming2();
+}
+
+//
+// Test overloading; the attribute is not required for overloaded types and
+// does not apply if not specified.
+//
+
+// CHECK-LABEL: @_Z12overloadedfni(
+// CHECK-SAME: #[[SM_ENABLED]]
+int  overloadedfn(int x) __arm_streaming { return x; }
+// CHECK-LABEL: @_Z12overloadedfnf(
+// CHECK-SAME: #[[NORMAL_DEF]]
+//
+float overloadedfn(float x) { return x; }
+// CHECK-LABEL: @_Z13test_overloadi(
+// CHECK-SAME: #[[NORMAL_DEF]]
+//
+int test_overload(int x) { return overloadedfn(x); }
+// CHECK-LABEL: @_Z13test_overloadf(
+// CHECK-SAME: #[[NORMAL_DEF]]
+//
+float test_overload(float x) { return overloadedfn(x); }
+
+// CHECK-LABEL: @_Z11test_lambdai(
+// CHECK-SAME: #[[NORMAL_DEF]]
+// CHECK: call noundef i32 @"_ZZ11test_lambdaiENK3$_0clEi"({{.*}}) #[[SM_ENABLED_CALL]]
+//
+// CHECK: @"_ZZ11test_lambdaiENK3$_0clEi"(
+// CHECK-SAME: #[[SM_ENABLED]]
+int test_lambda(int x) {
+  auto F = [](int x)  __arm_streaming { return x; };
+  return F(x);
+}
+
+// CHECK-LABEL: @_Z27test_template_instantiationv(
+// CHECK-SAME: #[[NORMAL_DEF]]
+// CHECK: call noundef i32 @_Z15template_functyIiET_S0_(i32 noundef 12) #[[SM_ENABLED_CALL]]
+//
+// CHECK: @_Z15template_functyIiET_S0_(
+// CHECK-SAME: #[[SM_ENABLED]]
+template <typename Ty>
+Ty template_functy(Ty x)  __arm_streaming { return x; }
+int test_template_instantiation() { return template_functy(12); }
+
+//
+// Test that arm_locally_streaming is inherited by future redeclarations,
+// even when they don't specify the attribute.
+//
+
+// CHECK: define {{.*}} @_Z25locally_streaming_inheritv(
+// CHECK-SAME: #[[SM_BODY]]
+__arm_locally_streaming void locally_streaming_inherit();
+void locally_streaming_inherit() {
+  streaming_decl();
+}
+
+// CHECK: attributes #[[SM_ENABLED]] = { mustprogress noinline nounwind optnone "aarch64_pstate_sm_enabled" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[NORMAL_DECL]] = { "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[SM_ENABLED_DECL]] = { "aarch64_pstate_sm_enabled" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[SM_COMPATIBLE]] = { mustprogress noinline nounwind optnone "aarch64_pstate_sm_compatible" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[SM_COMPATIBLE_DECL]] = { "aarch64_pstate_sm_compatible" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[SM_BODY]] = { mustprogress noinline nounwind optnone "aarch64_pstate_sm_body" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[ZA_SHARED]] = { mustprogress noinline nounwind optnone "aarch64_pstate_za_shared" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[ZA_SHARED_DECL]] = { "aarch64_pstate_za_shared" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[ZA_PRESERVED]] = { mustprogress noinline nounwind optnone "aarch64_pstate_za_preserved" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[ZA_PRESERVED_DECL]] = { "aarch64_pstate_za_preserved" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[ZA_NEW]] = { mustprogress noinline nounwind optnone "aarch64_pstate_za_new" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[NORMAL_DEF]] = { mustprogress noinline nounwind optnone "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+bf16,+sme" }
+// CHECK: attributes #[[SM_ENABLED_CALL]] = { "aarch64_pstate_sm_enabled" }
+// CHECK: attributes #[[SM_COMPATIBLE_CALL]] = { "aarch64_pstate_sm_compatible" }
+// CHECK: attributes #[[SM_BODY_CALL]] = { "aarch64_pstate_sm_body" }
+// CHECK: attributes #[[ZA_SHARED_CALL]] = { "aarch64_pstate_za_shared" }
+// CHECK: attributes #[[ZA_PRESERVED_CALL]] = { "aarch64_pstate_za_preserved" }

clang/test/Modules/aarch64-sme-keywords.cppm

+// REQUIRES: aarch64-registered-target
+//
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 -triple aarch64 -target-feature +sme %t/A.cppm -emit-module-interface -o %t/A.pcm
+// RUN: %clang_cc1 -std=c++20 -triple aarch64 -target-feature +sme -fprebuilt-module-path=%t -I%t %t/Use.cpp -emit-llvm
+// RUN: cat %t/Use.ll | FileCheck %s
+
+//--- A.cppm
+module;
+export module A;
+
+export void f_streaming(void) __arm_streaming { }
+export void f_streaming_compatible(void) __arm_streaming_compatible { }
+export void f_shared_za(void) __arm_shared_za { }
+export void f_preserves_za(void) __arm_preserves_za { }
+
+//--- Use.cpp
+// expected-no-diagnostics
+import A;
+
+// CHECK: define dso_local void @_Z18f_shared_za_callerv() #[[SHARED_ZA_DEF:[0-9]+]] {
+// CHECK: entry:
+// CHECK:   call void @_ZW1A11f_shared_zav() #[[SHARED_ZA_USE:[0-9]+]]
+// CHECK:   call void @_ZW1A14f_preserves_zav() #[[PRESERVES_ZA_USE:[0-9]+]]
+// CHECK:   ret void
+// CHECK: }
+//
+// CHECK:declare void @_ZW1A11f_shared_zav() #[[SHARED_ZA_DECL:[0-9]+]]
+//
+// CHECK:declare void @_ZW1A14f_preserves_zav() #[[PRESERVES_ZA_DECL:[0-9]+]]
+//
+// CHECK:; Function Attrs: mustprogress noinline nounwind optnone
+// CHECK:define dso_local void @_Z21f_nonstreaming_callerv() #[[NORMAL_DEF:[0-9]+]] {
+// CHECK:entry:
+// CHECK:  call void @_ZW1A11f_streamingv() #[[STREAMING_USE:[0-9]+]]
+// CHECK:  call void @_ZW1A22f_streaming_compatiblev() #[[STREAMING_COMPATIBLE_USE:[0-9]+]]
+// CHECK:  ret void
+// CHECK:}
+//
+// CHECK:declare void @_ZW1A11f_streamingv() #[[STREAMING_DECL:[0-9]+]]
+//
+// CHECK:declare void @_ZW1A22f_streaming_compatiblev() #[[STREAMING_COMPATIBLE_DECL:[0-9]+]]
+//
+// CHECK-DAG: attributes #[[SHARED_ZA_DEF]] = {{{.*}} "aarch64_pstate_za_shared" {{.*}}}
+// CHECK-DAG: attributes #[[SHARED_ZA_DECL]] = {{{.*}} "aarch64_pstate_za_shared" {{.*}}}
+// CHECK-DAG: attributes #[[PRESERVES_ZA_DECL]] = {{{.*}} "aarch64_pstate_za_preserved" {{.*}}}
+// CHECK-DAG: attributes #[[NORMAL_DEF]] = {{{.*}}}
+// CHECK-DAG: attributes #[[STREAMING_DECL]] = {{{.*}} "aarch64_pstate_sm_enabled" {{.*}}}
+// CHECK-DAG: attributes #[[STREAMING_COMPATIBLE_DECL]] = {{{.*}} "aarch64_pstate_sm_compatible" {{.*}}}
+// CHECK-DAG: attributes #[[SHARED_ZA_USE]] = { "aarch64_pstate_za_shared" }
+// CHECK-DAG: attributes #[[PRESERVES_ZA_USE]] = { "aarch64_pstate_za_preserved" }
+// CHECK-DAG: attributes #[[STREAMING_USE]] = { "aarch64_pstate_sm_enabled" }
+// CHECK-DAG: attributes #[[STREAMING_COMPATIBLE_USE]] = { "aarch64_pstate_sm_compatible" }
+
+void f_shared_za_caller(void) __arm_shared_za {
+  f_shared_za();
+  f_preserves_za();
+}
+
+void f_nonstreaming_caller(void) {
+  f_streaming();
+  f_streaming_compatible();
+}

clang/test/Sema/aarch64-sme-func-attrs.c

+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sme -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sme -fsyntax-only -verify=expected-cpp -x c++ %s
+
+// Valid attributes
+
+void sme_arm_streaming(void) __arm_streaming;
+void sme_arm_streaming_compatible(void) __arm_streaming_compatible;
+
+__arm_new_za void sme_arm_new_za(void) {}
+void sme_arm_shared_za(void) __arm_shared_za;
+void sme_arm_preserves_za(void) __arm_preserves_za;
+
+__arm_new_za void sme_arm_streaming_new_za(void) __arm_streaming {}
+void sme_arm_streaming_shared_za(void) __arm_streaming __arm_shared_za;
+void sme_arm_streaming_preserves_za(void) __arm_streaming __arm_preserves_za;
+
+__arm_new_za void sme_arm_sc_new_za(void) __arm_streaming_compatible {}
+void sme_arm_sc_shared_za(void) __arm_streaming_compatible __arm_shared_za;
+void sme_arm_sc_preserves_za(void) __arm_streaming_compatible __arm_preserves_za;
+
+void sme_arm_shared_preserves_za(void) __arm_shared_za __arm_preserves_za;
+
+__arm_locally_streaming void sme_arm_locally_streaming(void) { }
+__arm_locally_streaming void sme_arm_streaming_and_locally_streaming(void) __arm_streaming { }
+__arm_locally_streaming void sme_arm_streaming_and_streaming_compatible(void) __arm_streaming_compatible { }
+
+__arm_locally_streaming __arm_new_za void sme_arm_ls_new_za(void) { }
+__arm_locally_streaming void sme_arm_ls_shared_za(void) __arm_shared_za { }
+__arm_locally_streaming void sme_arm_ls_preserves_za(void) __arm_preserves_za { }
+
+// Valid attributes on function pointers
+
+void streaming_ptr(void) __arm_streaming;
+typedef  void (*fptrty1) (void) __arm_streaming;
+fptrty1 call_streaming_func() { return streaming_ptr; }
+
+void streaming_compatible_ptr(void) __arm_streaming_compatible;
+typedef void (*fptrty2) (void) __arm_streaming_compatible;
+fptrty2 call_sc_func() { return streaming_compatible_ptr; }
+
+void shared_za_ptr(void) __arm_shared_za;
+typedef void (*fptrty3) (void) __arm_shared_za;
+fptrty3 call_shared_za_func() { return shared_za_ptr; }
+
+void preserves_za_ptr(void) __arm_preserves_za;
+typedef void (*fptrty4) (void) __arm_preserves_za;
+fptrty4 call_preserve_za_func() { return preserves_za_ptr; }
+
+void shared_preserves_za_ptr(void) __arm_shared_za __arm_preserves_za;
+typedef void (*fptrty5) (void) __arm_shared_za __arm_preserves_za;
+fptrty5 call_shared_preserve_za_func() { return shared_preserves_za_ptr; }
+
+typedef void (*fptrty6) (void);
+fptrty6 cast_nza_func_to_normal() { return sme_arm_new_za; }
+fptrty6 cast_ls_func_to_normal() { return sme_arm_locally_streaming; }
+
+// FIXME: Add invalid function pointer assignments such as assigning:
+//   1. A streaming compatible function to a normal function pointer,
+//   2. A locally streaming function to a streaming function pointer,
+// etc.
+
+// Invalid attributes
+
+// expected-cpp-error@+4 {{'__arm_streaming_compatible' and '__arm_streaming' are not compatible}}
+// expected-cpp-note@+3 {{conflicting attribute is here}}
+// expected-error@+2 {{'__arm_streaming_compatible' and '__arm_streaming' are not compatible}}
+// expected-note@+1 {{conflicting attribute is here}}
+void streaming_mode(void) __arm_streaming __arm_streaming_compatible;
+
+// expected-cpp-error@+4 {{'__arm_streaming' and '__arm_streaming_compatible' are not compatible}}
+// expected-cpp-note@+3 {{conflicting attribute is here}}
+// expected-error@+2 {{'__arm_streaming' and '__arm_streaming_compatible' are not compatible}}
+// expected-note@+1 {{conflicting attribute is here}}
+void streaming_compatible(void) __arm_streaming_compatible __arm_streaming;
+
+// expected-cpp-error@+2 {{'__arm_new_za' and '__arm_shared_za' are not compatible}}
+// expected-error@+1 {{'__arm_new_za' and '__arm_shared_za' are not compatible}}
+__arm_new_za void new_shared_za(void) __arm_shared_za {}
+
+// expected-cpp-error@+2 {{'__arm_new_za' and '__arm_preserves_za' are not compatible}}
+// expected-error@+1 {{'__arm_new_za' and '__arm_preserves_za' are not compatible}}
+__arm_new_za void new_preserves_za(void) __arm_preserves_za {}
+
+// Invalid attributes on function pointers
+
+// expected-cpp-error@+4 {{'__arm_streaming_compatible' and '__arm_streaming' are not compatible}}
+// expected-cpp-note@+3 {{conflicting attribute is here}}
+// expected-error@+2 {{'__arm_streaming_compatible' and '__arm_streaming' are not compatible}}
+// expected-note@+1 {{conflicting attribute is here}}
+void streaming_ptr_invalid(void) __arm_streaming __arm_streaming_compatible;
+// expected-cpp-error@+4 {{'__arm_streaming_compatible' and '__arm_streaming' are not compatible}}
+// expected-cpp-note@+3 {{conflicting attribute is here}}
+// expected-error@+2 {{'__arm_streaming_compatible' and '__arm_streaming' are not compatible}}
+// expected-note@+1 {{conflicting attribute is here}}
+typedef void (*fptrty7) (void) __arm_streaming __arm_streaming_compatible;
+fptrty7 invalid_streaming_func() { return streaming_ptr_invalid; }
+
+// expected-warning@+2 {{'__arm_streaming' only applies to non-K&R-style functions}}
+// expected-error@+1 {{'__arm_streaming' only applies to function types; type here is 'void ()'}}
+void function_no_prototype() __arm_streaming;
+
+//
+// Check for incorrect conversions of function pointers with the attributes
+//
+
+typedef void (*n_ptrty) (void);
+typedef void (*s_ptrty) (void) __arm_streaming;
+s_ptrty return_valid_streaming_fptr(s_ptrty f) { return f; }
+
+// expected-cpp-error@+2 {{cannot initialize return object of type 's_ptrty' (aka 'void (*)() __arm_streaming') with an lvalue of type 'n_ptrty' (aka 'void (*)()')}}
+// expected-error@+1 {{incompatible function pointer types returning 'n_ptrty' (aka 'void (*)(void)') from a function with result type 's_ptrty' (aka 'void (*)(void) __arm_streaming')}}
+s_ptrty return_invalid_fptr_streaming_normal(n_ptrty f) { return f; }
+// expected-cpp-error@+2 {{cannot initialize return object of type 'n_ptrty' (aka 'void (*)()') with an lvalue of type 's_ptrty' (aka 'void (*)() __arm_streaming')}}
+// expected-error@+1 {{incompatible function pointer types returning 's_ptrty' (aka 'void (*)(void) __arm_streaming') from a function with result type 'n_ptrty' (aka 'void (*)(void)')}}
+n_ptrty return_invalid_fptr_normal_streaming(s_ptrty f) { return f; }
+
+// Test an instance where the result type is not a prototyped function, such that we still get a diagnostic.
+typedef void (*nonproto_n_ptrty) ();
+// expected-cpp-error@+2 {{cannot initialize return object of type 'nonproto_n_ptrty' (aka 'void (*)()') with an lvalue of type 's_ptrty' (aka 'void (*)() __arm_streaming')}}
+// expected-error@+1 {{incompatible function pointer types returning 's_ptrty' (aka 'void (*)(void) __arm_streaming') from a function with result type 'nonproto_n_ptrty' (aka 'void (*)()')}}
+nonproto_n_ptrty return_invalid_fptr_streaming_nonprotonormal(s_ptrty f) { return f; }
+
+typedef void (*sc_ptrty) (void) __arm_streaming_compatible;
+sc_ptrty return_valid_streaming_compatible_fptr(sc_ptrty f) { return f; }
+
+// expected-cpp-error@+2 {{cannot initialize return object of type 'sc_ptrty' (aka 'void (*)() __arm_streaming_compatible') with an lvalue of type 'n_ptrty' (aka 'void (*)()')}}
+// expected-error@+1 {{incompatible function pointer types returning 'n_ptrty' (aka 'void (*)(void)') from a function with result type 'sc_ptrty' (aka 'void (*)(void) __arm_streaming_compatible')}}
+sc_ptrty return_invalid_fptr_streaming_compatible_normal(n_ptrty f) { return f; }
+// expected-cpp-error@+2 {{cannot initialize return object of type 'n_ptrty' (aka 'void (*)()') with an lvalue of type 'sc_ptrty' (aka 'void (*)() __arm_streaming_compatible')}}
+// expected-error@+1 {{incompatible function pointer types returning 'sc_ptrty' (aka 'void (*)(void) __arm_streaming_compatible') from a function with result type 'n_ptrty' (aka 'void (*)(void)')}}
+n_ptrty return_invalid_fptr_normal_streaming_compatible(sc_ptrty f) { return f; }
+
+typedef void (*sz_ptrty) (void) __arm_shared_za;
+sz_ptrty return_valid_shared_za_fptr(sz_ptrty f) { return f; }
+
+
+// expected-cpp-error@+2 {{cannot initialize return object of type 'sz_ptrty' (aka 'void (*)() __arm_shared_za') with an lvalue of type 'n_ptrty' (aka 'void (*)()')}}
+// expected-error@+1 {{incompatible function pointer types returning 'n_ptrty' (aka 'void (*)(void)') from a function with result type 'sz_ptrty' (aka 'void (*)(void) __arm_shared_za')}}
+sz_ptrty return_invalid_fptr_shared_za_normal(n_ptrty f) { return f; }
+// expected-cpp-error@+2 {{cannot initialize return object of type 'n_ptrty' (aka 'void (*)()') with an lvalue of type 'sz_ptrty' (aka 'void (*)() __arm_shared_za')}}
+// expected-error@+1 {{incompatible function pointer types returning 'sz_ptrty' (aka 'void (*)(void) __arm_shared_za') from a function with result type 'n_ptrty' (aka 'void (*)(void)')}}
+n_ptrty return_invalid_fptr_normal_shared_za(sz_ptrty f) { return f; }
+
+typedef void (*pz_ptrty) (void) __arm_preserves_za;
+pz_ptrty return_valid_preserves_za_fptr(pz_ptrty f) { return f; }
+
+// expected-cpp-error@+2 {{cannot initialize return object of type 'pz_ptrty' (aka 'void (*)() __arm_preserves_za') with an lvalue of type 'n_ptrty' (aka 'void (*)()')}}
+// expected-error@+1 {{incompatible function pointer types returning 'n_ptrty' (aka 'void (*)(void)') from a function with result type 'pz_ptrty' (aka 'void (*)(void) __arm_preserves_za')}}
+pz_ptrty return_invalid_fptr_preserves_za_normal(n_ptrty f) { return f; }
+// No diagnostics, the preserves_za hint should be dropped silently.
+n_ptrty return_invalid_fptr_normal_preserves_za(pz_ptrty f) { return f; }
+
+// Test template instantiations
+#ifdef __cplusplus
+template <typename T> T templated(T x) __arm_streaming { return x; }
+template <> int templated<int>(int x) __arm_streaming { return x + 1; }
+template <> float templated<float>(float x) __arm_streaming { return x + 2; }
+// expected-cpp-error@+2 {{explicit instantiation of 'templated' does not refer to a function template, variable template, member function, member class, or static data member}}
+// expected-cpp-note@-4 {{candidate template ignored: could not match 'short (short) __arm_streaming' against 'short (short)'}}
+template short templated<short>(short);
+#endif
+
+// Conflicting attributes on redeclarations
+
+// expected-error@+5 {{function declared ''void (void) __arm_streaming_compatible'' was previously declared ''void (void) __arm_streaming'' with different SME function attributes}}
+// expected-note@+3 {{previous declaration is here}}
+// expected-cpp-error@+3 {{function declared ''void () __arm_streaming_compatible'' was previously declared ''void () __arm_streaming'' with different SME function attributes}}
+// expected-cpp-note@+1 {{previous declaration is here}}
+void redecl(void) __arm_streaming;
+void redecl(void) __arm_streaming_compatible { }
+
+// expected-error@+5 {{function declared ''void (void) __arm_shared_za'' was previously declared ''void (void) __arm_shared_za __arm_preserves_za'' with different SME function attributes}}
+// expected-note@+3 {{previous declaration is here}}
+// expected-cpp-error@+3 {{function declared ''void () __arm_shared_za'' was previously declared ''void () __arm_shared_za __arm_preserves_za'' with different SME function attributes}}
+// expected-cpp-note@+1 {{previous declaration is here}}
+void redecl_nopreserve_za(void) __arm_shared_za __arm_preserves_za;
+void redecl_nopreserve_za(void)  __arm_shared_za{ }
+
+#ifdef __cplusplus
+struct S {
+  virtual void shared_za_memberfn(void) __arm_shared_za;
+};
+
+struct S2 : public S {
+// expected-cpp-error@+2 {{virtual function 'shared_za_memberfn' has different attributes ('void ()') than the function it overrides (which has 'void () __arm_shared_za')}}
+// expected-cpp-note@-5 {{overridden virtual function is here}}
+  __arm_new_za void shared_za_memberfn(void) override {}
+};
+
+// Check that the attribute propagates through template instantiations.
+template <typename Ty>
+struct S3 {
+  static constexpr int value = 0;
+};
+
+template <>
+struct S3<void (*)()> {
+  static constexpr int value = 1;
+};
+
+template <>
+struct S3<void (* __arm_streaming)()> {
+  static constexpr int value = 2;
+};
+
+void normal_func(void) {}
+void streaming_func(void) __arm_streaming {}
+
+static_assert(S3<decltype(+normal_func)>::value == 1, "why are we picking the wrong specialization?");
+static_assert(S3<decltype(+streaming_func)>::value == 2, "why are we picking the wrong specialization?");
+
+template<typename T> int test_templated_f(T);
+template<> constexpr int test_templated_f<void(*)(void)>(void(*)(void)) { return 1; }
+template<> constexpr int test_templated_f<void(*)(void)__arm_streaming>(void(*)(void)__arm_streaming) { return 2; }
+
+static_assert(test_templated_f(&normal_func) == 1, "Instantiated to wrong function");
+static_assert(test_templated_f(&streaming_func) == 2, "Instantiated to wrong function");
+
+// expected-cpp-error@+2 {{'__arm_streaming' only applies to function types; type here is 'int'}}
+// expected-error@+1 {{'__arm_streaming' only applies to function types; type here is 'int'}}
+int invalid_type_for_attribute __arm_streaming;
+
+// Test overloads
+constexpr int overload(void f(void)) { return 1; }
+constexpr int overload(void f(void) __arm_streaming) { return 2; }
+static_assert(overload(&normal_func) == 1, "Overloaded to wrong function");
+static_assert(overload(&streaming_func) == 2, "Overloaded to wrong function");
+
+// Test implicit instantiation
+template <typename T> struct X {
+  static void foo(T) __arm_streaming { }
+};
+constexpr int overload_int(void f(int)) { return 1; }
+constexpr int overload_int(void f(int) __arm_streaming) { return 2; }
+constexpr X<int> *ptr = 0;
+static_assert(overload_int(ptr->foo) == 2, "Overloaded to the wrong function after implicit instantiation");
+
+#endif // ifdef __cplusplus