- User Since
- Oct 15 2014, 9:44 AM (402 w, 6 d)
Thu, Jun 9
Yep, committed c68b469e0788, thanks!
May 26 2022
May 20 2022
May 11 2022
Hi @nikic, I may have hit an issue with this change: when the noop-bitcast result is already used in other (potentially already selected) blocks, we already assigned a vreg for the value, and it may be too late to change it when selecting this bitcast. Concretely, this repro fails for x86_64 with -verify-machineinstrs, because the second use of %tmp1 uses a never-defined vreg:
Apr 20 2022
Apr 14 2022
Sure, filed 54914 to cherry-pick into 14.0.2
Apr 12 2022
D'oh, this fell through the cracks, sorry folks! I committed the fix I had in mind (cfa4fe7c5187). Long story short: this change exposed an old bug in the LOH pass: it wasn't honoring regmasks in bundled MIs, but since we used to split the bundle and emit the attached call separately, the (unbundled) latter was still visible to the pass. That's not true as of this change. I think for the sort of code that uses bundles on aarch64 it's usually selectors that get corrupted in a later msgSend, and that ends up exploding in dyld the way we're seeing in both cases.
Mar 23 2022
Reading this again, I have a feeling defaulting to newest will come back to bite us (or, well, apple folks.) But we can reevaluate if we get to that. So, LGTM, thanks!
Ah, further down, there's a different crash signature in bisect6.txt, in dyld strlen: that one does ring a bell. I assume it's handling a corrupt selector, but there's not much context to know for sure. I have a later change that may take care of that, hopefully that resolves your original crash as well!
Mar 9 2022
Mar 7 2022
Mar 2 2022
Feb 18 2022
Feb 14 2022
I committed a modified description, happy to make more changes:
Feb 11 2022
Feb 8 2022
Jan 28 2022
Jan 26 2022
Jan 25 2022
Jan 24 2022
Same, makes sense, thanks!
Jan 18 2022
Dec 13 2021
Dec 8 2021
Dec 1 2021
Quite the old TODO, nice ;) LGTM!
Makes sense, LGTM!
Nov 18 2021
Nov 14 2021
Thanks all for the reviews! 68854f4e572a
Nov 11 2021
Hey folks! Any more comments?
Nov 8 2021
Nov 4 2021
Simplify err_ptrauth_disabled diagnostic, rebase.
Nov 1 2021
Link to ELF PAuth ABI Extension. Refer to ISA extension as "PAuth" (and clarify relationship with "Armv8.3-a" and "Pointer Authentication Code")
Oct 28 2021
Oct 25 2021
Rebased; updated docs following Pablo's comments.
Oct 11 2021
Sep 15 2021
Aug 17 2021
Jul 26 2021
Thanks all so far! Any other suggestions or comments?
Rebase; describe auth/resign as side-effect-free (matching IntrNoMem) and mention they can be eliminated.
May 25 2021
Rewrote a good chunk of the document following reviews, responded inline to some. Thanks all for the comments!
May 19 2021
Thanks all, now landed! I still need to find some time to rewrite the bits about the mailing lists and mention ours.
May 17 2021
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)
May 11 2021
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?
May 3 2021
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
Apr 27 2021
Thanks all! I'll add Kate to the group and issue tracker.
Apr 26 2021
Apr 20 2021
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?
Apr 12 2021
Mar 25 2021
Thanks George, and welcome!
Mar 17 2021
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.