[llvm] r194253 - [ARM] In ARMAsmParser, MatchCoprocessorOperandName() permitted p10 and p11 as operands for coprocessor instructions, resulting in encodings that clash with FP/NEON instruction encodings

Joerg Sonnenberger joerg at britannica.bec.de
Sun Dec 1 16:06:29 PST 2013

On Sun, Dec 01, 2013 at 10:39:48AM +0000, Tim Northover wrote:
> > This commit breaks valid assembler sources that use MCR/MRC explicitly
> > in place of the (newer) NP/NEON forms.
> I believe those sources are (strictly) invalid on v6 and above. All
> coprocessor instructions begin with "if coproc in '101x' then SEE
> 'floating-point instructions", terminology that's used elsewhere for
> cases which don't permit overlap.
> > I don't see the point of this
> > change and therefore would like to see it reverted on trunk and 3.4.
> From Artyom's point of view, it's probably making sure LLVM adheres to
> the reference manuals. For the writers of the reference manuals, I
> suspect the problem is running out of encoding space and having to use
> (say) MRC-type encodings for instructions that have absolutely nothing
> MRC-like about them -- better to completely forbid the misleading
> forms than leave confusion.
> Personally, I don't see the argument for keeping this as an alias on
> post-v5 architectures. I can't think of a use that wouldn't be better
> served by writing it in terms of the real FP instructions.

It breaks compatibility with existing code. As I said, I still haven't
heard an argument for why it is needed. Deprecate them and don't add new
aliases -- fine. But removing something that has been accepted for a
long time?


More information about the llvm-commits mailing list