[PATCH] D63707: [AArch64] Define ETE and TRBE system registers

[Pablo Barrio via Phabricator via llvm-commits]

pbarrio added a comment.

These are trace extensions that will be used by a niche group of developers. They add no instructions (only system registers) and they will not be generated by the compiler. Adding them by default does not have any side-effect, i.e. everyone will still see the same behavior in their code unless they start using these registers on purpose.

IMHO avoiding a command line option will give us a better implementation story going forward.

Without a command line option:

- Someone wants to use ETE & TRBE right now: just write code using the registers.
- The command line can be anything that compiles for aarch64, via the "generic" target.
- When there is a decision about where these extensions will land, we move them outside the generic target and put them where they really belong.
- This will break some people, but I think this is actually good. We don't want someone building with ETE & TRBE enabled in an armv8.2-a image if the extensions finally land in a newer armv8.x-a.

With a command line option:

- You have to enable the extension, which is an unnecessary step because you will not get anything out of it unless you explicitly use the registers.
- The only benefit would be an error message if you try to use the registers and build without the extension. However, at this point in time this is not too important (actually I would find it annoying): if someone is using the extension, it is because they really know what they are doing.
- When these extensions finally land in some architecture armv8.x-a, we may enable them by default there. However, someone using ETE & TRBE and building for armv8.2+ete+trbe will not see any error, will keep generating images that use these extensions, and these binaries may even be distributed to be run in armv8.2-a cores, which will obviously fail at runtime.

Ideally, the AArch64 back-end would have a HasV8_0aOps TargetFeature, and we would add ETE & TRBE there. Since adding HasV8_0aOps requires some proper refactoring, I think the generic processor is a good place to put them for now. Do you have any issue in mind that could come up if we add these extensions to the generic processor model?

Additionally, I personally like better the idea that users will know for sure (via test failures) when we change the minimum architecture for these features. Also we avoid adding yet another architecture extension that may be deprecated soon. Can you anticipate any problem if we don't add a command line option?


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

https://reviews.llvm.org/D63707