Page MenuHomePhabricator

dmaclach (Dave MacLachlan)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 10 2018, 7:47 PM (77 w, 3 d)

Recent Activity

Wed, May 13

dmaclach added a comment to rGdbfa453e4138: [CodeGen][ObjC] Make copying and disposing of a non-escaping block no-ops..

So this is probably old news inside of Apple, but this can cause [NSInvocation retainArguments] to crash:

Wed, May 13, 5:29 PM

Jan 16 2020

dmaclach accepted D72876: Create a clang-tidy check to warn when -dealloc is implemented inside an ObjC class category..
Jan 16 2020, 2:53 PM · Restricted Project, Restricted Project
dmaclach requested changes to D72876: Create a clang-tidy check to warn when -dealloc is implemented inside an ObjC class category..
Jan 16 2020, 2:15 PM · Restricted Project, Restricted Project

Sep 25 2019

dmaclach added a comment to D67865: [clang-tidy] Finds uses of OSRead* calls on macOS that may mask unexpected behavior due to unaligned reads.

Any other comments on this?

Sep 25 2019, 4:52 PM · Restricted Project

Sep 23 2019

dmaclach updated the diff for D67865: [clang-tidy] Finds uses of OSRead* calls on macOS that may mask unexpected behavior due to unaligned reads.

Updated based on review

Sep 23 2019, 4:25 PM · Restricted Project
dmaclach added inline comments to D67865: [clang-tidy] Finds uses of OSRead* calls on macOS that may mask unexpected behavior due to unaligned reads.
Sep 23 2019, 3:11 PM · Restricted Project
dmaclach updated the diff for D67865: [clang-tidy] Finds uses of OSRead* calls on macOS that may mask unexpected behavior due to unaligned reads.

Fixed up review comments.

Sep 23 2019, 3:09 PM · Restricted Project

Sep 20 2019

dmaclach created D67865: [clang-tidy] Finds uses of OSRead* calls on macOS that may mask unexpected behavior due to unaligned reads.
Sep 20 2019, 2:41 PM · Restricted Project

May 16 2019

dmaclach added a comment to rL345516: [libc++] Use exclude_from_explicit_instantiation instead of always_inline.

Okay, so I've looked into it a little bit further and it's really just that when we force inlining everything, we basically end up with a lot fewer functions being defined in the object file, and consequently the resulting code is smaller. It's not rocket science and it's what I expected.

Now, what I'm thinking is that perhaps what you might want to do is crank up the inliner using compiler flags instead of trying to influence that in the library. I'm not exactly sure how/whether one can do that, but it seems like what you want may be something like: clang++ -falways-inline or something along those lines. This would have the "added benefit" that all your code would get the same treatment, not only libc++. Does that make sense?

May 16 2019, 2:29 PM

May 14 2019

dmaclach added a comment to rL345516: [libc++] Use exclude_from_explicit_instantiation instead of always_inline.

-O0 for everything I'm complaining about here :)

May 14 2019, 2:58 PM
dmaclach added a comment to rL345516: [libc++] Use exclude_from_explicit_instantiation instead of always_inline.

OK, here's for Google Maps (a mix of ObjC, ObjC++, C++) with multiple TU:

May 14 2019, 1:39 PM

May 13 2019

dmaclach added a comment to rL345516: [libc++] Use exclude_from_explicit_instantiation instead of always_inline.

Chromium bug 961450 is tracking to see if it causes size/performance changes there as well

May 13 2019, 2:30 PM
dmaclach added a comment to rL345516: [libc++] Use exclude_from_explicit_instantiation instead of always_inline.

As a piece of test code:

May 13 2019, 2:25 PM
dmaclach added a comment to rL345516: [libc++] Use exclude_from_explicit_instantiation instead of always_inline.

Hey Louis,

May 13 2019, 1:08 PM

May 10 2019

dmaclach added a comment to rL345516: [libc++] Use exclude_from_explicit_instantiation instead of always_inline.

This change caused some significant bloat and affected our performance and link times.

May 10 2019, 1:24 PM

Dec 13 2018

dmaclach added a comment to D55544: Warning: objc-encodings-larger-than=.

Akira/John/Erik - any thoughts?

Dec 13 2018, 5:17 PM · Restricted Project
dmaclach added inline comments to D55640: [clang-tidy] Implement a check for large Objective-C type encodings 🔍.
Dec 13 2018, 5:15 PM · Restricted Project

Dec 11 2018

dmaclach updated the diff for D55544: Warning: objc-encodings-larger-than=.

Updated to fix Stephane's good catch of Objective C vs Objective-C

Dec 11 2018, 11:11 AM · Restricted Project
dmaclach updated the diff for D55544: Warning: objc-encodings-larger-than=.

Full Diffs as requested.

Dec 11 2018, 11:09 AM · Restricted Project
dmaclach added a comment to D55544: Warning: objc-encodings-larger-than=.

It would probably be a good idea to have a similar check on properties, as property encoding strings contain the type encoding (plus extra stuff).

Dec 11 2018, 9:22 AM · Restricted Project
dmaclach updated the diff for D55544: Warning: objc-encodings-larger-than=.

Added some spacing around early exit as requested by theraven.

Dec 11 2018, 9:19 AM · Restricted Project

Dec 10 2018

dmaclach created D55544: Warning: objc-encodings-larger-than=.
Dec 10 2018, 8:01 PM · Restricted Project