[PATCH] D71046: Support Intel "l" suffixes for x86_64 R8-R15 registers.

Michael Trent via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 5 14:02:17 PST 2019


mtrent added a comment.

In D71046#1771414 <https://reviews.llvm.org/D71046#1771414>, @craig.topper wrote:

> Do you have examples of other tools that accept this? I checked the GNU assembler and it didn't accept r8l


I don't. I know Apple's (old) GNU-based assembler does not accept r8l. I do not know if Intel provided tools that accept r8l, but that's the most likely candidate. I'm going from some (old) user reports stating it should work, as well as documentation found online, such as:

https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf
https://software.intel.com/en-us/articles/introduction-to-x64-assembly
https://stackoverflow.com/questions/1753602/what-are-the-names-of-the-new-x86-64-processors-registers
https://stackoverflow.com/questions/43991779/why-does-apple-use-r8l-for-the-byte-registers-instead-of-r8b

The first intel URL documents r8l exclusively. The second intel URL seems to favor r8b while acknowledging r8l. The stackoverflow links seem to explain why the world prefers using the AMD register names.

I don't have overly strong feelings about this. If r8l and friends are strictly just alternate strings of r8b this seems like a reasonable request for compatibility with code written using r8l. Again, based on some developer feedback I have, there do exist people who expect r8l to work, for whatever reason. If there were a convenient way to force people to opt into this alternate syntax I could go for that, although I don't know of an existing case that handles this, and I don't think this is worth creating some new flag or classification. If someone with "sufficient authority" were to say this Intel syntax is no longer valid, or if LLVM will not support it, I'm also OK with dropping this request and returning my bug reports as "Not To Be Fixed".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71046





More information about the llvm-commits mailing list