[PATCH] D39910: [ARM] Issue an eror when non-general-purpose registers used in address operands (alternative)

[Momchil Velikov via Phabricator via llvm-commits]

chill added a comment.

In https://reviews.llvm.org/D39909#924657, @chill wrote:

> Correct me if I'm wrong ...
>
> For me it seems that the approach of returning just true/false from the asm operand class predicates, while
>  good for weeding out invalid instructions, isn't that great for diagnostics. The operand may be invalid for
>  a variety of reasons, but we have only one diagnostics string, which can at best list all the possible constraints
>  and let the user figure out by themselves what's wrong.
>
> For example, assembling:
>
>   vld1.16 {d0}, [s0:64]
>
>
> with `llvm-mc -triple=armv7a-eabi` gives `error: alignment must be 64 or omitted`, and if we need to improve
>  this message, we'd have to list the constrain that the register must be GPR. And do that for all/lot-of the other
>  `AsmOperandClasss`es, which would create a huge number of repetetetetitions of the constraint "X must be a GPR".
>  If we instead diagnose usage of non-GPR registers in the parser, and leave checking more specific constraints
>  (like "X must not be PC" or "X must be SP") to asm operand class predicates, some diagnostics will be more
>  precise and the rest will require less effort by the user, because that'd list a comparatively small number of
>  constraints to manually check.


Having said that, I still tried this approach to a few asm operand classes and the results look promising.

Anyway, I suggest separating the correctness check for general-purpose registers from a set of follow-up of patches, which
just improve the error message "invalid operand for instruction".


https://reviews.llvm.org/D39910