Sam's suggestion to me for the ACLE intrinsics was that there should be an IR intrinsic that converts the i16 provided by the user into an <n x i1> for whatever n makes sense. In my unpushed (and unpolished) draft implementation there's also one that converts back again, which the ACLE intrinsics will need for the return value of vcmp. So it could be used here as well if that's useful.

Hmm. I may have underestimated the difficulty, then! My thought was that all I really needed was to arrange that if you already had a v2i1, you could use it as the predicate operand for one of the 64-bit-lane instructions and not have instruction selection fail, and perhaps if you already had a pair of them you could do bitwise ops between them just like you can with all the others.

So it sounds as if the most immediate problem is that there now _isn't_ an architecture you can specify on clang's command line that permits the union of all the instructions you plan to use?

Hmmm. This surely can't be the first time a case like this has come up. What's the usual solution in other similar situations, when you want to include code for mutually incompatible architectures in the same object because you're going to test at run time which one to execute?

Revised patch is intended to apply after D63938 rather than before.

Revised patch fixes those two target triples in the tests, and makes the setAllExpand calls for f32 and f64 conditional on different things. Also, to make that less cumbersome, I've moved a few re-enabling setOperationAction calls into setAllExpand itself which otherwise had to be run after every single call.

I can't shed as much light as you might hope, I'm afraid, but in D62998 my intention was not to make -mcpu=anything win over -mfpu=anything. It was to make an explicit request to enable a feature win over an implicit request to disable it. It so happened in my example that the explicit request was in the -mcpu option.

Otherwise LGTM.

Apparently it would: trying it that way, it does look simpler, and as far as I can tell it doesn't change the output of any currently checked-in Tablegen input.

Sorry about that. rL364635 should fix it.

Changed my mind about the opt-in system: instead of using a subclass of OperandWithDefaultOps, I've switched to using a flag field inside the existing class.

Rebased this patch to current trunk, and also fixed a test failure by adding arm_aapcs_vfpcc to the test functions that use MVE vector types (since we can't support passing vector types in GPRs until we get all the operations like build_vector and insert_element fully supported).

Revised this patch to work properly with all the other MVE-related changes we've been making.

Addressed all review comments.

Addressed all review comments, I think.

I committed this this morning as rL364172, but accidentally left off the Phabricator footer (sorry). Now closing.

Minor revisions to this patch: changed a couple of legacy t2rGPR into rGPR (after the former was withdrawn during code review of D63650). Also added a small knock-on fix in checkTargetMatchPredicate, preventing an assertion failure in a check that was specific to rGPR.

Reworked the remaining loads and stores to address review comments, implement consistent naming of instruction ids, and tidy up the Tablegen so that it's hopefully halfway readable.

Updated instruction spellings in line with intended consistent MVE practice, and also reworked the WLSTP/DLSTP and LETP/LCTP definitions to remove pointless !if from the base classes. (In particular, the instructions that don't have a label field in the encoding now don't have one in their Tablegen defs either.)

Addressed all review comments.

I've decided this patch is too large to manage all in one go. Also, the interleaving family of loads (VLD20 and friends) share essentially no infrastructure with the VLDR family, so that seems like a natural place to split the patch in two.

Revised the VIDUP immediate operand handling so as to draw a distinction between the general concept 'power of 2 which is encoded as a left-shift count in the instruction', and the specific case used in VIDUP which takes a fixed range of inputs and has a custom DiagnosticString as you suggested that explains what it's used for.

Addressed review comment about Mnemonic.startswith("vmul"), and also updated this patch to use the existing NEON complex rotation operands (with matching change in the test to expect the new nicer error messages).

Added tests for invalid condition codes, and also added custom DiagnosticStrings that improve the error messages.

Removed the new operand classes for complex rotation, and added new operand classes for fixed-point VCVT immediates which do the error checking.

(I'm still working on the rest of your review comments)

Updated instruction id naming in line with intended MVE policy. Also added a comment explaining the complicated MC operand-juggling for these instructions with tricky asm syntax.

Renamed instruction records in line with the intended MVE naming policy. Also generally tidied up while I was going along, by creating multiclasses and merging pairs of base classes where it saved space.

Updated to rename instruction classes in line with the general MVE policy. Also, I spotted some instructions lurking in the middle of this section of ARMInstrMVE.td which aren't derived from the MVE_qDest_qSrc base class, so they should have been part of earlier patches. Moved them into D62674 and D62675 where they belong.

Added the floating-point VMINNMA / VMAXNMA instructions to this patch, which were mistakenly included in D62677 despite not being derived from the latter patch's shared base class.

Added the integer VMINA / VMAXA instructions to this patch, which were
mistakenly included in D62677 despite not being derived from the
latter patch's shared base class.

Updated to rename instruction classes in line with the general MVE policy. Also improved the custom decoder function for the VCMP family, by eliminating the huge secondary switch inside it on the opcode (instead we now pass in template parameters from Tablegen, which already knew what the opcode should be) and adding a comment explaining why that function even needs to be there.

Renamed instruction ids in line with the new policy (start with MVE_ and don't refer to opaque ArmARM encoding indices).

Addressed all review comments. In particular, completely removed the mve.fp test run from the mve-integer.s test file, because it was only there due to copy and paste error (I split all these tests out of one far-too-big input file with a single set of run commands).

Addressed minor review comments (isVectorIndex family, pointless
suffixes on size{1-0} and similar). Also, fixed the incomprehensible
mess of MVE vector indices by rewriting the MVE_VMOV_lane class
hierarchy completely: by splitting it up in the other order (first by
lane size, then by transfer direction) I managed to arrange that the
lane index operand becomes a perfectly normal integer which doesn't
even need custom encode/decode methods at all.

Updated to current trunk, and renamed instruction ids in line with new
consistent MVE_ prefix.