[PATCH] D39712: [ARM] Add an alias for psr and psr_nzcvq

Kristof Beyls via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 10 00:50:01 PST 2017


kristof.beyls added a comment.

In https://reviews.llvm.org/D39712#917604, @olista01 wrote:

> Hi Leslie,
>
> As far as I can tell, this is a gcc extension (it's not in any architecture reference manual I can find), which I can't find any documentation for. Is this correct, or is there some documentation I've missed? If I'm right, I'm not sure that there's any compelling reason to support this in LLVM. I've added Renato, who might know more about our policy for adding these sort of non-standard extensions.
>
> If we do implement it, this isn't the right way to do it, you have given the "psr" operand a different encoding than "xpsr". In gcc's implementation, "psr" and "xpsr" result in exactly the same instructions. I've added Javed, who implemented this table-driver operand parsing, he might have some ideas about the best way to implement aliases.
>
> As for the test, this is not the right file to put it in, I'd suggest adding it to test/MC/ARM/thumb2-mclass.s instead.


FWIW, I don't think I've seen enough supporting material to add this to LLVM.
Is there any specification or documentation that documents "psr"?
What was the rationale for adding this seemingly un-specified extension to gas? Would the same rationale make us accept this patch in LLVM?
How much code in the world uses this? Couldn't just the pieces of code that use this get fixed? In that case, maybe providing a diagnostic indicating that "xpsr" should be used instead of "psr" is the most programmer-friendly option to implement in LLVM?
Just implementing more and more undocumented, non-standard and un-specified extensions to the assembler syntax will make the assembler worse, not better, IMHO.


Repository:
  rL LLVM

https://reviews.llvm.org/D39712





More information about the llvm-commits mailing list