[TableGen] Add PreferSmallerInstructions for Targets.

[AlfieRichardsArm]

This option means that in assembly matching instructions with smaller encodings will be preferred.

This will be used for the ARM instruction set where this is the correct behavior after some other refactoring.

[AlfieRichardsArm]

@kosarev This is a PR for the addition of the PreferSmallInstructions option

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[kosarev]

Thanks. LGTM modulo the typo. But please don't submit until this is actually needed.

[AlfieRichardsArm]

@s-barannikov Regarding

I think this check should be tie-breaking rather than defining, and so it should be moved below, after we've compared the number of operands and their classes.
Also, does this check supersede the AVX/AVX512 resolution below?

It is my understanding this needs to be here for ARM. The architecture reference manual states:

If neither .W nor .N is specified, the assembler can select either a 16-bit or 32-bit encoding. If both encoding
lengths are available, it must select a 16-bit encoding.

There are cases (such as thumb 1 instructions with a CCOut operand whereas thumb 2 doesnt) where the smaller instruction has more operands, so choosing that first would make this non-compliant.

[AlfieRichardsArm]

@s-barannikov regarding

Should it be a member of AsmParser instead?

I have just pushed a commit that moves it.

[s-barannikov]

Move to AsmMatcherEmitter.cpp?

[AlfieRichardsArm]

Sure!

[AlfieRichardsArm]

-        if (A.couldMatchAmbiguouslyWith(B, Target)) {
+        bool PreferSmallerInstructions =
+            AsmParser->getValueAsBit("PreferSmallerInstructions");
+        if (A.couldMatchAmbiguouslyWith(B, PreferSmallerInstructions)) {

@s-barannikov: Same for shouldBeMatchedBefore above.

Fixed.

[AlfieRichardsArm]

#83436 (comment)

I would add to this comment

(a) that this flag is useful for Arm (so that people who only know other architectures have an idea why it needs to be here in the first place)

Adding this now

(b) what the preference order is if this flag is false. (Surely the only reason this flag exists, instead of just being always-true, is so that somebody can deliberately set it to false, in which case they have some reason to want a different preference order, and will need to know how to get it.)

The main reason for this flag is this change breaks a lot of assumptions that other backends (MIPS primarily) rely upon (see all the assumptions it broke in the ARM backend to get an idea (: ). I will add a comment to explain the default ordering and the change this makes.

[statham-arm]

I'm happy with this from the point of view of it filling in the missing comment I asked for on review #83436. I can't comment on whether the details of the specified preference order are accurate, though, so I have to rely on other reviewers for that :-)