I plan to remove the options useDeprecatedPositionallyEncodedOperands, decodePositionallyEncodedOperands, and
noNamedPositionallyEncodedOperands, which may be set in a Target’s “InstrInfo” tablegen definition. See also the current documentation.
If you maintain a private downstream target, you will need to update your target to use named matching, if you haven’t already done so. The fixes for most in-tree targets were pretty simple, but did identify a variety of minor bugs (and accordingly, missing test-coverage). For some examples on the easy side, see the changes for ARM/AArch64 (only the parts in lib/Target), or SPARC and further cleanup, or AVR. On the other hand, PowerPC (not coincidentally, one of the oldest targets in LLVM!) (1, 2) required a significant amount of cleanup work. Hopefully you’ll find your out-of-tree targets on the simpler side!
I’ve also uploaded a proposed commit for review, but am starting a thread here as well, to raise visibility.
Some history and background:
More than 10 years ago, TableGen’s instruction encoder was given the ability to match operands to fields in an instruction definition by name, instead of requiring/assuming that fields in the tablegen instruction definition are defined in the same order as the operands. From then on, it has been a source of confusion and bugs that both named field matching AND positional field matching can happen.
A few months ago, I started making a series of changes (1 2 3) to add the last bits of missing functionality to allow named operand matching to cover all use-cases, and then, to deprecate positional matching and turn it off by default. After a series of follow-up changes, which have cleaned up the in-tree targets, I would like to finally remove the support for positional operand matching, in order to simplify the code and make way for further cleanup work.