I can't see any other uses of the option groups, or any way to put an option into two groups, so this LGTM.

Is there an existing compiler which this option is trying to be compatible with? GCC for AArch64 doesn't currently have an option for this, so we don't have to worry about compatibility with that. If possible, I'd prefer for the option to be "-mtp=", to match the option accepted by clang and GCC for AArch32.

LGTM. Do you have commit access? If not, I can commit this for you.

LGTM

LGTM with one nit .

LGTM

LGTM

LGTM

Yes, the back-end work was all done years ago, I just also forgot about these while waiting for the ACLE to be published.

Ping

These macros have been in the published ACLE for a while now: https://developer.arm.com/products/software-development-tools/compilers/arm-compiler-5/docs/101028/latest/5-feature-test-macros#position-independent-code

I think it would be neater to move this annotation printing code to after the regular printAliasInstr/printInstruction calls at the end of the function (line 300). As it is, this patch will drop any other annotations on the instruction, because it doesn't call printAnnotation(O, Annot).

LGTM, but please remember to upload with more context.

LGTM with one minor nit.

Why do you think this would be better as a target hook, rather than in the datalayout? The datalayout already includes information about alignments of different types, and most of the target hooks are concerned with what IR will be efficient for the target, not things which might affect correctness.

LGTM with one nit.

LGTM, thanks.

What is the use-case for wanting to use SP_ELx for the thread pointer, instead of TPIDR_ELx?

LGTM, thanks!

LGTM with one nit.

LGTM.

LGTM with one nit.

LGTM with one nit.

In the ARM backend, we only use variable_ops for the LDM and STM instructions, where the variadic operands are either all uses or all defs. I'm less familiar with the other backends, but all of the other cases where variable_ops is used look similar.

I can't think of any general way to test this, because these properties of MCInsts are not used much. The Thumb instructions which this applies to are tested by test/MC/ARM/implicit-it-generation.s, which has a big list of PC-writing instructions which cannot be used in the middle of an IT block, this patch is NFC for them.

A few nits, but otherwise LGTM, no need to re-review after fixing them.

I can provide a full log of the 4831 warnings marked -Winline-asm during a Firefox for ARM Android build, if you're interested.

• Make the "cc" inline assembly clobber affect all status registers
• Handle tied operands correctly in the AsmMatcher (fixes post-increment ldr/str instructions)
• Fix outputs of t2AsmPseudo records (fixes Thumb2 mov with shifted right-hand operand)
• Call transferInlineAsmOps in cases where we parse more than one operand at once

mpi_arm.c:

• For the warnings which are emitted, some register MCOperands are being matched against the wrong parsed operand.
• For post-increment instructions, the assembly matcher is not setting the writeback register in the MCInst (leaving it as noreg), because it is tied to one part of a complex operand, which it doesn't support. The fix for this might be to make a similar change to rL209425 in the ARM backend, which would give other advantages (better diagnostics for memory operands).

For the first example, it looks like we're missing the case where a memory instruction with writeback modifies the address register. I'll have a look and see if there's a way to fix that.

However, the ID_AA64MMFR2_EL1 register was added in v8.2. So I believe we should check as to warn the user if he might get undefined behavior by accessing it when not present.

There currently isn't even a user interface to reserve X16.

Remove special case in MCInstrDesc::mayAffectControlFlow, which is no longer needed.

This is only used for the -debug output (i.e. things inside the LLVM_DEBUG macro) and from within a debugger, I don't think we tend to test that.