Rewrote a good chunk of the document following reviews, responded inline to some. Thanks all for the comments!

Thanks all, now landed! I still need to find some time to rewrite the bits about the mailing lists and mention ours.

Rebased, split tests by intrinsic rather than by GISel vs SDAG (since GISel is now always built and we don't need the separate test directory)

Ah sorry, I didn't see you tried that already! I don't think we want to weaken the verifier check, this is probably the only case where it makes sense to take the address. I guess we've meandered through the same decision process, thanks for the patience ;) But it might be worth explaining these decisions in the commit message. Also in the langref paragraph for the bundle, it says the call is always emitted for the bundle.
Which brings another idea: how about emitting the call when lowering the bundle on AArch64 as well? There's not much room for better regalloc or other optimizations in the sequence anyway, right?

Thanks for the comments! Tweaks inline

• mention public discussions on lists/in sync-up, link to sync-up page
• describe Github workflow as potentially useful for publicly disclosing resolved issues

Thanks all! I'll add Kate to the group and issue tracker.

In D94597#2632887, @fhahn wrote:

Unfortunately the ObjC runtime matches different sequences on AArc64 and X86. This is documented here https://github.com/opensource-apple/objc4/blob/master/runtime/objc-object.h#L974

On AArch64, the callee only checks for mov x29, x29 in the caller and the position of the claim/autorelease runtime call does not matter, which makes things much simpler. On X86_64, it specifically looks for the marker instructions, immediately followed by the runtime call. So we want to make sure that it is very hard to break up this specific sequence, to avoid missing out on the runtime optimization.

Neat, thanks!

This sounds nice! One idea, maybe more dangerous, not sure which is better: in setTripleTypeForMachOArchName, we already have a couple setArchName calls, I think that's why arm64e is left alone in the aarch64-cpus.c test. Maybe we can do the setArchName call for every arch there?

Thanks George, and welcome!

Can you (or @ahatanak) explain why/how this needs to be different from aarch64? In particular I don't think I understand why you need to emit the retainARV/claimARV calls this late, that seems like quite a drastic difference in behavior for the bundle.
I read through the discussion in D92808 but it sounds like that predates the x86_64-specific behavior, right? But skimming around the various passes involved I'm not actually sure who emits the retainARV/claimARV calls on aarch64.

Thanks Tim! f77c948d56b

No objection here (but let's leave a few more days, per process)*. Thanks Artur, and thanks @reames for helping get the group going!

Reformat ValidArchs.

In D87095#2255010, @pcc wrote:

But I was wondering: shouldn't this be the *last* patch? I was imagining that you would first upstream support for the -fptrauth-* flags, and then at the end you would add an arm64e subarch that turns them on by default. Otherwise the upstream compiler will temporarily produce ABI-incompatible objects when targeting arm64e.

Hmm, is there a more general way to disable warnings? I'm not familiar with these parts, so I'll defer to you folks =]

This looks sensible, modulo a couple inline comments

In D84276#2172756, @arsenm wrote:

In D84276#2172675, @paquette wrote:

In rG55d10423a6a1f8286be05651b9c7143ef4e58b22

[GlobalISel] Don't translate intrinsics with metadata parameters.
Some intrinsics take metadata parameters. These all need custom handling of some form, and cannot possibly be lowered generically to G_INTRINSIC calls with vreg operands. Reject them, instead of hitting an assert later in getOrCreateVReg.

Is this still relevant? I guess we're just using custom legalization and selection to handle these nowadays?

(@ab do you have opinions here?)

In D82699#2118313, @arphaman wrote:

@t.p.northover @ab I noticed that the use of "apple-a12" doesn't infer the right target features when we're passing in a11 or older, so that's why my test file has the INFER-A12 separate line. Do you think this is a bug? This is decided here:

else if ((A = Args.getLastArg(options::OPT_mcpu_EQ)))
  success = getAArch64ArchFeaturesFromMcpu(D, A->getValue(), Args, Features);

and CPU value isn't checked here.

Is it possible to make the (defaulting mcpu to "apple-latest") decision in a library, instead of in llvm-objdump and other individual tools?

Seems reasonable. This is an interesting use of MCID flags, in that llvm itself doesn't need it, but I'm all for better disassembler support!