- User Since
- Oct 18 2012, 4:53 AM (364 w, 6 d)
Updating diff. How target features are handled changed slightly upstream.
Thu, Oct 10
Wed, Oct 9
Fri, Oct 4
Thu, Oct 3
Fair enough. Still fine I think.
Looks reasonable to me.
Mon, Sep 30
Fri, Sep 27
Fri, Sep 20
First, it appears that the current codegen (CAS loop) for 128-bit atomic accesses is broken based on this comment: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814#c3. There are two problematic cases as far as I understand: (1) const and (2) volatile atomic objects. Const objects disallow write access to the underlying memory, volatile objects mandate that each byte of the underlying memory shall be accessed exactly once according to the AAPCS. The CAS loop violates both.
Sep 13 2019
Thanks for pinging me, I don't get notifications for plain relpies to whatever Phabricator calls this. I'll get it sorted.
Sep 12 2019
Thanks Amara, it's r371722.
Sep 11 2019
Sep 9 2019
Added comments mostly, and undid some changes to tests.
Thanks Amara. r371384.
Aug 27 2019
Thanks Eli. r370036.
Changed my mind and only run MachineDominator above O0. The faff involved in estimating the performance penalty properly just isn't worth the small amount of work to make the issue go away.
Aug 23 2019
My one concern is with adding the machine dominator analysis the the pipeline at -O0. Is there a significant compile time cost?
Aug 22 2019
Updated according to most comments.
Aug 16 2019
Thanks Hal. Committed as r369091.
Aug 15 2019
Aug 9 2019
Aug 7 2019
Unfortunately I don't think this is viable for Darwin platforms, at least not yet. Our compact unwind encoding just has a bitmask for which registers are saved rather than saying where relative to fp.
Aug 6 2019
Aug 5 2019
Ah sorry, it was part of an NFC change in a different commit. I've rolled it into this diff; it's splitting off GEP sinking from the useAA callback since they're not really related.
Aug 3 2019
Thanks Reid, committed as r367755.
Aug 2 2019
- Added release note
- Added hacky script to utils so that I can refer to it from the release note.
- Removed "<badref>" handling from printArgument. Printing a free-standing Argument goes down a different path.
Aug 1 2019
Jul 20 2019
What a horrible function. AAPCS? Who cares about that?
Jul 19 2019
Jul 11 2019
Jul 9 2019
Thanks David. Committed with your suggestions as r365468.
Jul 8 2019
- Switched back to SmallVector to track registers used, reducing code perturbation. I decided to add a SmallSet too for queries instead of using std::find_if directly because searches actually happen regardless.
- Disabled special handling for [N x i32] except on arm64_32 MachO.
- Noticed a bug in 2 above, where we allocated 2N registers anyway and fixed it.
- Added getPointerType comment.
At a high level, my main care about here is that what is upstreamed here doesn't conflict with also adding support at some point in the future for the AArch64 ILP32 ABI - for which a beta quality specification from Arm exists.
Jul 4 2019
Looks reasonable to me.
Jul 2 2019
Sorry for the double reply, Phab ate my comment.
Jun 28 2019
How about this: https://reviews.llvm.org/differential/diff/207034/?revisionID=63842.
Jun 27 2019
Thanks. Should be committed as r364550.
I think the clang-format should be restricted to the actual diff. Doing the whole file makes this change really hard to read, and disrupts the blame for the future. git-clang-format in the Clang repo does the right thing by default I think.
Jun 26 2019
Jun 11 2019
This diff now only covers the trivial additions so that "arm64_32" is understood by the driver and creates AArch64 instantiations of relevant classes. Code generated is still wildly incorrect (not even ILP32 yet).
Thanks for the suggestion Florian, and sorry it's taken so long to act on it. I've split the patch up as you suggest, I'll make this one cover the Triple bits.
Jun 5 2019
May 31 2019
May 30 2019