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!

(but either way, LGTM)

Sorry for the delay; go ahead, the patch looks OK.

Please check the embedded thing (the other comments are minor). Otherwise, LGTM; if you have found this flag to be necessary, this looks like a reasonable way to implement it

Hmm, if I may: what do you want to support? I'd expect Apple to upstream their own patches.

Thanks for checking, much appreciated!

On second thought, what happens to the tablegen emitter? That needs to be taught about these as well, right? That might not trigger on anything right now though.

Nice!

Looks good, thanks!

LGTM, thanks!

LGTM, ty!

LGTM, thanks!

A few minor comments inline, and one question: it sounds like this is based on a GCC feature; what's the expected behavior for __builtin_returnaddress ? Shouldn't it xpaci the result?

LGTM. Not the biggest fan of CodeGen/Generic tests, but it gets the job done, I suppose ;) I wouldn't be surprised if it failed on some target that can't even handle half parameters, so you might want to load it instead, put it in x86, or wait and see - your pick.