This discussion seems to have wound down. I'll land this patch tomorrow on the strength of @LukeGeeson's review, unless you have strong objections, @jfb?

In D85009#2187643, @jfb wrote:

Language-wise I think https://wg21.link/p1467 is where C++ is going, and C is taking a similar approach.

In D85009#2187621, @jfb wrote:

You mean: only aarch64 backend supports lowering bfloat16 vectors at the moment?

In D85009#2187549, @jfb wrote:

Is that true of all vector bfloat implementations? It seems like arithmetic on these types is something implementations would likely support.

@jdoerfert , @clementval : over in D83032 is a polished-up version of the script I used to check where the missing deps needed to go. Might be useful for the next problem of this kind. But I'm not sure who to get to review it; perhaps one of you might look at it?

In D82659#2125618, @clementval wrote:

LGTM. So later the DEPENDS omp_gen that are in clang subdirectories could be removed right?

[facepalm] Thank you. I carefully wrote a revised description, but forgot to upload it to this issue.

Here's a completely different patch, which adds all the missing dependencies on OMP.h.inc in the clang subdirectory in one go.

Cannot you just add a depends for your failing case?

Unfortunately, I had to revert this because it caused a buildbot failure: rG39ea5d74b283d5a42f34b856d22bfaf806a1c907

@clementval , are you happy for me to commit this patch?

I wondered about that. I think it may well mean some of those DEPENDS can be removed, but I'm not sure how to be certain of it :-)

LGTM. Thanks for the fixes.

Updated for @dmgreen's review suggestions, which both seem to work as far as I can see.

It isn't unused – there are still some isel patterns using it, which I haven't touched in this commit.

(Sorry @labrinea – removing you as a reviewer was an unintentional side effect of a bad arc command.)

New version addressing review comments.

OK, fair enough. In that case, please correct my nitpicks and I'll approve the revised patch.

for ARMv7 we only disallowed this pair, and this change removes that restriction. So now, all of them are allowed...

I've made a couple of nitpicks to the patch, but my more general question is: if we think that this pair of coprocessors should be changed from "reject completely" to "accept with a warning", why not all of them? What argument applies to CP10 and CP11 that doesn't apply to all the others, apart from the immediate short-term argument of "this is the one that's currently causing somebody a problem"?

I see. In that case I suppose the simplest thing to do is just to explain that in the commit message, along the lines of "D77872 has already added the MC representations of the instructions so that they can be used in code gen; this patch fills in the details needed to make assembly parsing work, and adds tests for asm and disasm'.

The important part of this patch seems to be missing! It says it's adding AArch32 assembly parsing for some new instructions, but I don't see any new Tablegen work that adds the instructions. New mnemonics are added to a couple of exclusion lists in ARMAsmParser, but there's no code in here that makes the mnemonics actually exist in the first place, or that says what their operands should be or what their encodings are – just that small C++ tweak and a load of tests. Where's the rest of it?

I have no thoughts on the patch itself, but the commit message looks quite alarming out of context. Perhaps it should mention that you're doing this specifically for i1 and vectors of i1, and not for bitwise OR of ordinary integers?

In D76910#1945744, @samparker wrote:

Are we talking about CONSTRAINED_UNPREDICTABLE here?

Do you understand why all those test outputs have changed as a side effect of this?

Added an entry to the Clang release notes as well.

LGTM, with only one tiny remaining nitpick.

Update tests to fix CI failure (oops). Also added opt -sroa to make the incidental half/float argument marshalling a bit less verbose.