See https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html, documentation for "mharden-sls": For AArch64, the options available on the command line are "retbr", "blr", "none" and "all".
I don't think the options necessarily have to be the same for x86.
But assuming I understand this patch correctly, it seems to me that with this patch -mharden-sls=all would mean fundamentally slightly different things for x86 vs arm and aarch64, which could be confusing to users.
IIUC this patch correctly, this patch implements the equivalent of aarch64/arm's -mharden-sls=retbr (i.e. add a straight-line-speculation mitigation for returns and indirect jumps, but not for indirect function calls).
Therefore, I wonder if it wouldn't be better to name this -mharden-sls=retbr for more consistency across architectures?
Or is the indirect function call case not relevant for x86 (sorry - I'm not up to speed on the details on the x86 side)?

committed as https://github.com/llvm/llvm-project/commit/ac2f0a6f1d4b3f5ff61dac33d9aba395d79b6a3d

updated guidance based on Aaron's feedback.

Use correct syntax to indicate we're adding a subsubsection, not a section, see https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#sections

LGTM

LGTM, thank you!

LGTM, thank you @voltur01 !

I'm afraid I don't know if it's possible to check anywhere in public documentation that the values 0xc0 and 0xac3 are correct.
I'm assuming you verified those are the correct.
The code looks good, apart from one place where clang-format suggests different indentation.
With that indentation adapted, this looks good to me.

LGTM, thank you!

I think this would be useful to have, as writing fine-grained filter rules is not necessarily easy or even doable in some mail clients, such as gmail.
With that in mind, I wonder if this action (which if I understand correctly will add a comment mentioning "@issue-subscribers-label"), results in the corresponding notification email adding "issue-subscribes-label@noreply.github.com"? I hope it does as that probably would make it easier to write email filters.

I just have 2 bike-sheddy comments on the documentation text.
My comments should not let you delay in getting this committed if they do not make sense to you.

LGTM, thanks.

LGTM - thanks for fixing this!

GNU binutils has a specific option to silence the warnings about deprecated IT blocks (-m{no-}warn-restrict-it), see https://sourceware.org/legacy-ml/binutils/2019-12/msg00093.html.
I haven't looked up if GNU tools have the equivalent of -no-deprecated-warn.

@MaskRay - gentle ping: I wonder if you have any further remarks after I updated the patch based on your earlier feedback?

run clang-format on the patch.

Updated test based on feedback from @MaskRay

LGTM, thank you for fixing this!

LGTM, thanks!

On a side note, it looks like llvm/test/CodeGen/ARM/speculation-hardening-sls.ll doesn't contain many of the check lines I would expect any more, after e497b12a69604b6d691312a30f6b86da4f18f7f8. Is that expected, or should I make a patch to undo that?

For speculation-hardening-sls.ll: the approach taken in the ARM backend version of the similar test is probably a lot more robust, and I'd guess that if the test was adapted to follow the approach there ( see https://github.com/llvm/llvm-project/blob/566690b067c8175314fa657b899c99bccf96821c/llvm/test/CodeGen/ARM/speculation-hardening-sls.ll#L343), the compiler would still use the x16 register.

I'm afraid that I'm not fully up to speed on the code changes here.
That being said, I hope it's useful to point out that I expect that in the not-too-distant future the recent specification of r11 being the frame pointer for both Arm and Thumb to be implemented in LLVM. See https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst (search for "frame pointer") to see the specification. A frame pointer was only recently added to the ABI specification. Before there was no definition of frame pointer for 32-bit ARM in the ABI specification.

In D108679#2965397, @dpaoliello wrote:

In D108679#2964617, @kristof.beyls wrote:

The performance deprecation of certain forms of IT blocks has been reverted.
The performance deprecation notes are being removed from the Arm ARM.
I am expecting that in the near future, code generation for Arm will be adapted to not enable -mrestrict-it by default at all, following what was already done in gcc at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-12/msg00134.html.

As such, I'm not sure if this patch is a good thing to implement.
Maybe the guidelines in Microsoft's document you point to (https://docs.microsoft.com/en-us/cpp/build/overview-of-arm-abi-conventions?view=msvc-160#it-instructions) should be adapted to take into account the above described changes to the ArmARM?

@kristof.beyls Can you please point me to any official documentation or announcement from ARM about this (I've tried looking myself but couldn't see anything)?
I'd be happy to abandon this change and get the Microsoft docs updated if these instructions are no longer deprecated.

The performance deprecation of certain forms of IT blocks has been reverted.
The performance deprecation notes are being removed from the Arm ARM.
I am expecting that in the near future, code generation for Arm will be adapted to not enable -mrestrict-it by default at all, following what was already done in gcc at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-12/msg00134.html.

In D106906#2929835, @nikhgupt wrote:

How many more approvals are needed for this to be final? According to D99232, it looks like eight?

In D104094#2817317, @pcc wrote:

Do we still need the DSB on line 119?

Thank you Stephen; LGTM!

In D103080#2790139, @sunlin wrote:

Hi @kristof.beyls The original lib/clang/12.0.1/include is about total ~10M, and the arm*.h take about ~5M. Ignore these unused header files will save the developers who work on the low storage device.

I'm wondering what the rationale for this change is.
If there is a good rationale for this; wouldn't it need to be applied to all target-specific header files, not only the Arm-specific header files?

LGTM.

Thanks @danielkiss !
I only have a few nit picky remarks.
Overall looks good!

LGTM, thank you Ahmed!

Thanks for this Ahmed!
This mostly looks good to me, I just have a few nit-comments inline.

Apart from maybe needing to run clang-format on the patch, the code changes look good to me.
Before this could be committed, this needs tests.

I approve. Thanks George!

In D98797#2634898, @lattner wrote:

This is fantastic! I'd recommend mentioning this on llvm-dev / and to Alex @ llvm-weekly when it goes up.

Addressing feedback + also adding a pointer to the various flang and openmp regular sync-ups.

Make capitalization consistent

Thanks Chris.
Now updated following all of your suggestions.