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

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127762