[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D127762#3960906 <https://reviews.llvm.org/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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127762/new/

https://reviews.llvm.org/D127762