It seems to me that this patch would also need:

• Some regression test to test it actually changes code generation (only?) when targeting Arm.
• As is, this patch will not result in changed code generation IIUC?

Adding Snehasish as a reviewer as git blame suggests snehasish has designed and written most of the MachineFunctionSplitter.

LGTM, thank you!

LGTM, thank you!

I just have a few more very minor nit-picky comments. Feel free to disagree with them.
I'm happy for this to go in.
I haven't looked in detail into the comments @DavidSpickett mad , so please also explicitly get his approval before committing.

My apologies for missing this outstanding review for so long.

Looks great. Thank you for becoming an office hours host!

In D135431#3846049, @adeelahmad81299 wrote:

I've reuploaded the changed diff. Can you see it now?

In D135431#3842534, @adeelahmad81299 wrote:

I have updated the file and have run 'arc diff' command.

I just have one minor suggestion.
Otherwise, LGTM.

LGTM, thanks!

I finally found time to go through the patch from beginning to end. I only have 2 more - hopefully minor questions.
Apart from that, LGTM.

I seem to remember that the speculative_load_hardening for AArch64 has a work-around when a user does reserve register X16 in inline assembly, see comment at https://github.com/llvm/llvm-project/blob/b7dae832e61da1f8b48cce1715514cbd5809eb3f/llvm/lib/Target/AArch64/AArch64SpeculationHardening.cpp#L35.
Given that comment and the tests in https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/AArch64/speculation-hardening-dagisel.ll that check that behaviour, the warning/error implemented in this patch is not correct?

I had just 2 more minor nitpicks - mostly about adding 2 more regression tests to test/document expected behavior in corner cases.

LGTM!
I just added a few minor nitpicks - I'll leave it to you to decide if following those suggestions would result in an improvement or not.

See https://reviews.llvm.org/D56305 and https://reviews.llvm.org/D48580 for previous related discussions.
I think it would be helpful to understand the use case for being able to reserve x8, x16, x17 and x19 better.

My understanding is that X8, X16, X17 and X19 cannot be reserved because the code generator in places will make use of them.
For example, using X19 as a base register in some cases. X16 and X17 are defined by the ABI to potentially be clobbered on function calls & when a veneer needs to be inserted by a linker, it does get clobbered. IIRC, some of the security mitigations implemented in LLVM also clobber these 2 registers on function calls.
I'm not fully sure why X8 cannot be reserved.

In D132018#3731050, @thieta wrote:

How about a list of subdirectories with different licenses in the end of the top level LICENSE file? Then there is no need to keep the text in sync but only add / remove to the list in the end of the file when we add or remove a third-party dependency, which should be pretty infrequent.

In D132018#3729830, @tonic wrote:

In D132018#3729809, @lattner wrote:

This is a great idea, thank you for doing this. I think we should also point out the sublicenses that are not llvm licensed, e.g. we have a copy of PCRE, googletest etc, and should notify people about these things.

Agreed. We need to make sure that all licenses (ie MIT License as well) are accounted for here otherwise it makes things confusing if someone assumes everything is under only this license.

Otherwise I like this idea. I'm slightly concerned about it getting out of date if we add any other code with some new license.

As this is something I suggested - this LGTM.

gentle ping.

In D127852#3593826, @tonic wrote:

This can be another patch, but I would like to add a point of contact to all sync-ups for CoC purposes. This should also be included in the calendar notes. I'm happy to create the patch though.

In D127852#3593151, @beanz wrote:

This is awesome and a huge win!

Can you also make a PR to the llvm-www repo to get this posted on the main llvm.org page?

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.