This infrastructure should be enough to let you use the vector types in C as a means of getting them to and from __asm__ blocks that do the real work. I suppose that means I should include some tests that exercise exactly that, using asm operations in IR.

It's tested for v8.1-M, by llvm/test/MC/ARM/thumbv8.1m.s which is added by D60706. I could add an extra test or two to this patch for other affected architectures, if you think it's necessary.

The aim of this change is that it will apply to the v8.1-M (mainline) architecture introduced in D60698, in which +fp won't be the default: -march=armv8.1m.main by itself gives you the base 8.1-M architecture without any FP, -march=armv8.1m.main+fp gives you the optional single-precision FP extension on top of that, and +fp.dp gives you double precision as well.

It's true that during internal development we implemented this rename before the later change that adds some UnsupportedFeatures to the same schedule model which should rule out the MVE VMAXNM/VMINNM instructions in any case.

Yes, it is.

Adjusted message wording as suggested.

Simpler version that just replaces DenseMap with std::map.

I'm happy to do that if you prefer – I left the DenseMap in place on the Chesterton's Fence principle. (I didn't know why it was originally chosen over std::map, so hesitated to unilaterally reverse the decision.)

I'm not as familiar with the NEON FP16 instructions, but in a quick
look I didn't see a corresponding issue with predicating them – e.g.
the vector vadd.f32 and vadd.f16 are just as predicable as each
other, unlike the scalar ones.

Could I ping this, please? I've added the assembler check @efriedma asked about; is there anything else I need to change?

Added an error check in ARMAsmParser and a test that exercises it.

Good question. Testing it with llvm-mc, what seems to happen (with this patch applied) is that if I write one of these instructions after an explicit it instruction then I get "error: instructions in IT block must be predicable", but if there's no preceding IT then it's accepted without complaint.

Could I give this a gentle ping, please?

I've just come back to this patch after being distracted for several weeks (sorry about that). I intend to actually commit it shortly, and this time I'll try not to forget :-)

Name is rewritten between creation of LHSOp and RHSOp, so you
can't just make both of them into StringRefs because LHSOp would be
invalidated by the change to Name.

OK, here's a second draft which names the variables more sensibly. Perhaps slight overkill, in that I've used LHSOp and RHSOp for the variables ordered as they are in the source constraints string, and then DestOp and SrcOp once they're reordered to (what should be) a def and a use.

Can you add some tests for the affected instructions?

LGTM. (But I learned something new when I dug into lit to find out why you could get away with using single quotes – I would have expected that only double quotes would work on Windows!)

Oops, sorry about that :-(

Actually, on second thoughts, I'm going to assume it was overcautious to ask for a re-approval, since this version of the patch introduces no new controversy and in fact removes the only previous tweak in the Tablegen core (in that I'm not trying to change the semantics of anonymous any more). So I'll commit this as is, based on the previous review approval.

Nearly forgot to mention the new option in the tblgen man page!