I've a added a few words of documentation here: https://reviews.llvm.org/D73459

There's obviously lexer ambiguity in interpreting, e.g. the character sequence $4 as a single <identifier> token, or as the two tokens $ and a <constant>.
Looks like the tokenisation needs to be context dependent: in certain directives (.global $4) and instructions (b $4) the sequence needs to be interpreted a single identifier, and
in other contexts (ldr r0, [r0, $4]) as two separate tokens.

In D72633#1827691, @efriedma wrote:

I don't like fiddling with the ABI based on CPU features; it's common to mix code with different CPU features enabled (particularly for desktop/mobile CPUs; less so on microcontrollers, but it can still happen).

If we want to support some other ABI for performance reasons, we should make the user request it explicitly.

Absolutely, we are definitely not proposing a new ABI.

In D72633#1825260, @efriedma wrote:

In D72633#1823616, @chill wrote:

In D72633#1822545, @efriedma wrote:

It is not redundant with respect to -mfloat-abi=soft, as it leaves the door open to passing integer vector arguments via the so-called "FP registers".

So then "-mfloat-abi=hard -mfpu=none" means "pass floating-point values in registers, but don't use any other floating-point operations"?

No, it does not mean that, at least not yet, and it's not immediately obvious if that would be of any advantage. But it does affect integer vectors.

In D72633#1822545, @efriedma wrote:

It is not redundant with respect to -mfloat-abi=soft, as it leaves the door open to passing integer vector arguments via the so-called "FP registers".

So then "-mfloat-abi=hard -mfpu=none" means "pass floating-point values in registers, but don't use any other floating-point operations"?

No, it does not mean that, at least not yet, and it's not immediately obvious if that would be of any advantage. But it does affect integer vectors.

In D72633#1820382, @efriedma wrote:

In terms of the user-visible behavior, I guess my question is whether it would make sense to add "-mfpu=mve"/"-mfpu=mve.fp", and make "-mfpu=none" mean "no FP registers". I'm not sure why a user would specify "-mfpu=none" if they didn't want to disable the floating-point registers altogether.

In D72633#1817710, @SjoerdMeijer wrote:

I guess this makes probably sense, but just checking why this should have the effect of enabling MVE-I? Is there prior art -mfpu=none has a similar effect?

Ping?

Ping?

Closing manually, since I misspelled "Diferential" in the commit message.

In D71266#1778483, @efriedma wrote:

Is there some reason we can't handle these using tablegen'ed data, like other instructions?

In a sense we do use tablegen, it just that tablegen says "defer that to C++ code". (cf. "dynamic uops" in ARMScheduleA8.td and ARMScheduleA9.td).

Will commit next week, since we're on the move and might not be able to promptly react to breakage.

In D70407#1754833, @sigvartmh wrote:

Question: Is this sufficient to generate code which sets the processor into non-secure handler/thread mode? I'm fine with not having everything clean up all the registeres etc. I'm just going to use it for testing purposes at the moment to prepare a build system to handle llvm as a back-end for ARMv8-m.

In D62394#1672551, @sigvartmh wrote:

Maybe I'm doing something wrong tried to apply these patches but when trying to build code which uses cmse I get

Cannot select: intrinsic %llvm.arm.cmse.tt
fatal error: error in backend: Cannot select: intrinsic %llvm.arm.cmse.tt
clang-10: error: clang frontend command failed with exit code 70 (use -v to see invocation)

Ping?

Added some comments.

V8 needs to save a specific set of registers at the entry of a function depending on the type of this function. For example, a JS function needs to save r0, r1,r7 along with fp, lr. And a wasm function needs to spill r3 at sp - 16.

Moved parsing of branch protection spec to TargetParser.

Rebase, retest.
A wild CFGuardLongjmpPass appeared in the meantime, but it does not create instructions, only symbols, AFAICT, so
its placement is fine.

Moved parsing out of Attr.td to TargetInfo, following the example (good or bad) of validateOutputConstraint or validateGlobalregisterVariable ;)
Now issue a warning if attribute is not supported by target, like for other unsupported target options.

Ping?

Ping?

I'm a bit unsure how much we're willing to pollute the namespace: in this particular case looking at the four __bitcast_* functions.
I appreciate that getting rid of them would require emitting LLVM IR bitcasts, so a bit more effort compared to the macro approach.

Ping?

In D69118#1714163, @ostannard wrote:

For testing, we have the SPACE pseudo-instruction, which can be used to emulate very large basic blocks, maybe you could reduce your reproducer using that?

Updated pipeline tests.

In D68916#1708356, @efriedma wrote:

Adding aliases seems like the right approach; we have aliases for a bunch of other instructions.

I'm not sure why you need the AsmMatchConverter, though; needs a comment to explain.

Why is Rt listed twice here?

In D68862#1708079, @carwil wrote:

IMHO, since reserved registes are per-function, this strongly suggests implementation as function attribute(s), rather than subtarget features (also for the pre-existing r9).

What do you mean reserved registers are per-function? That sounds like you're describing local register variables, which I don't believe Clang has any support for (and there aren't a great deal of use-cases for anyway).
We're specifically talking about global usage here.

TBH, I quite dislike the creeping abuse of SubtargetFeatures as code generation options.