Page MenuHomePhabricator

dexonsmith (Duncan P. N. Exon Smith)
User

Projects

User does not belong to any projects.

User Details

User Since
Mar 18 2014, 10:33 AM (315 w, 3 d)

Recent Activity

Yesterday

dexonsmith committed rG0c85c488e2b5: utils: Tweak clang-parse-diagnostics-file for modules includes (authored by dexonsmith).
utils: Tweak clang-parse-diagnostics-file for modules includes
Thu, Apr 2, 2:39 PM
dexonsmith closed D77321: utils: Tweak clang-parse-diagnostics-file for modules includes.

LGTM.

Thu, Apr 2, 2:38 PM
dexonsmith resigned from D76594: [clang][AST] Support AST files larger than 512M.

@rsmith, @dexonsmith, @jdoerfert could you please take a look to this diff?
If you think that there are other reviewers who might have more context AST persistence, please add them.

Thu, Apr 2, 1:33 PM · Restricted Project
dexonsmith created D77321: utils: Tweak clang-parse-diagnostics-file for modules includes.
Thu, Apr 2, 10:50 AM

Tue, Mar 31

dexonsmith added a comment to D77058: [Clang] Add llvm.loop.unroll.disable to loops with -fno-unroll-loops..

I think this is a good approach, rather than a per-function attribute, since as mentioned this will be preserved through inlining.
@dexonsmith, does that seem reasonable to you? I missed the original patch and agree with you that we don't want to fix this in LTO by passing the option through to LTO.

Tue, Mar 31, 1:44 PM · Restricted Project

Fri, Mar 27

dexonsmith updated subscribers of D76916: [Darwin] Respect -fno-unroll-loops during LTO..

@fhahn, please revert, this isn't how we usually pass options in LTO.

Fri, Mar 27, 6:12 PM · Restricted Project

Wed, Mar 18

dexonsmith added a comment to D76290: [lit] Allow passing extra commands to executeShTest.
In D76290#1930134, @yln wrote:

I don't understand yet what this enables. Please extend your commit message to elaborate a bit more for people (like me) who aren't familiar with libcxx testing.
Does this enable deriving new tests from existing source files or running existing tests (.{pass,fail,sh}.cpp) in a different way without needing to modify those dozens/hundreds of files?

The change itself looks innocent enough and I don't want to block you on adding a test if there are currently none at all. LGTM.

Wed, Mar 18, 5:55 PM · Restricted Project

Sat, Mar 14

dexonsmith added a comment to D76178: [lit] Recursively apply substitutions.

It would also be good to confirm that this isn't expensive in the normal case (one-level substitutions). Have you timed running the libc++ tests with and without this patch?

Sat, Mar 14, 10:11 AM · Restricted Project
dexonsmith requested changes to D76178: [lit] Recursively apply substitutions.

This looks really cool. Can you add tests for this feature, somewhere inside llvm/utils/lit/tests?

Sat, Mar 14, 10:11 AM · Restricted Project

Fri, Mar 13

dexonsmith accepted D76075: Revert "[ObjC][ARC] Check the basic block size before calling DominatorTree::dominate".
Fri, Mar 13, 11:49 AM · Restricted Project

Thu, Mar 12

dexonsmith added a reviewer for D76075: Revert "[ObjC][ARC] Check the basic block size before calling DominatorTree::dominate": fhahn.

This SGTM. Ideally we'd confirm the compile-time explosion is fixed before landing this though.

Thu, Mar 12, 11:56 AM · Restricted Project

Wed, Mar 4

dexonsmith added a comment to D72068: [IR] Refactor SubclassData.

Given the contention around direction, I would suggest that you seek consensus via an RFC on llvm-dev before pinging the patch any further.

It is the first thing that I did, but I was asked to post the patch for review. I agree that there should have been more discussion in the mail, but it seems stranger (and with not much response) to ping a mail thread.
Please refer to http://lists.llvm.org/pipermail/llvm-dev/2020-January/138710.html for further details.

Wed, Mar 4, 4:20 PM · Restricted Project

Mar 4 2020

dexonsmith added a comment to D72068: [IR] Refactor SubclassData.
In D72068#1889825, @rnk wrote:

I'm still basically not in favor of this. If another contributor thinks it's a great idea, I wouldn't go so far as to block this change, but I don't plan to do any further review.

Fair enough, I respect your opinion.
However, I still think it is a very welcoming change (for the many reasons listed in the "summary"), and I hope other reviewers will see the benefits as I see them, and approve this change.

Mar 4 2020, 11:47 AM · Restricted Project
dexonsmith added inline comments to D72860: [modules] Do not cache invalid state for modules that we attempted to load..
Mar 4 2020, 10:38 AM · Restricted Project

Mar 2 2020

dexonsmith added a comment to D75395: [clang][Modules] Add -fsystem-module flag.

This is used when
converting an implicit build to an explicit build to match the
systemness the implicit build would have had for a given module.

I had another thought. What if for the explicitly built "system" modules:

  • If -Wsystem-headers is on, leave them as user modules in the explicit build.
  • If -Wsystem-headers is off, turn off all diagnostics in the explicit build.

    Does that give the right semantics, or is there something subtly different?

I considered this, but decided against it because I wanted the implicit and explicit builds to be as similar as possible, and reduce the amount of changes made to the original command line. There's a lot of code in Clang dealing with system files, and I'm not 100% sure that -Wno-everything would be equivalent.

Mar 2 2020, 3:53 PM · Restricted Project
dexonsmith added a comment to D75395: [clang][Modules] Add -fsystem-module flag.

This is used when
converting an implicit build to an explicit build to match the
systemness the implicit build would have had for a given module.

Mar 2 2020, 2:09 PM · Restricted Project
dexonsmith added inline comments to D75395: [clang][Modules] Add -fsystem-module flag.
Mar 2 2020, 2:09 PM · Restricted Project

Feb 28 2020

dexonsmith added a reviewer for D75323: Support relative dest paths in headermap files: bruno.
Feb 28 2020, 12:01 PM · Restricted Project
dexonsmith accepted D75213: RFC: More principled implementation of DISubprogram::describes().

Okay, LGTM then, as long as...

Feb 28 2020, 11:51 AM · Restricted Project, debug-info
dexonsmith added a comment to D75213: RFC: More principled implementation of DISubprogram::describes().

I'm inclined to try to commit this and see if we get any "describes" assertion reports.

Feb 28 2020, 9:55 AM · Restricted Project, debug-info

Feb 26 2020

dexonsmith added a comment to D75213: RFC: More principled implementation of DISubprogram::describes().

If you're worried about LTO, I suggest trying a clang bootstrap with each of -flto=full and -flto=thin. I was using the former as a testcase when I was doing this work, so I think we'd get good signal from that.

Feb 26 2020, 3:15 PM · Restricted Project, debug-info
dexonsmith accepted D74784: [driver][darwin] Don't use -platform_version flag by default.

LGTM to me too. With @steven_wu and me on board, I don't think you need to wait for @arphaman. Thanks for the fix!

Feb 26 2020, 11:23 AM · Restricted Project, Restricted Project

Feb 25 2020

dexonsmith updated subscribers of rG396b7253944e: [OpenMP][Opt] Combine `struct ident_t*` during deduplication.
Feb 25 2020, 6:55 PM

Feb 24 2020

dexonsmith added a comment to D75067: [LTO][Legacy] Add new API to query Mach-O CPU (sub)type.

@thegameg , tests are usually done through the llvm-lto or llvm-lto2 tools.

Feb 24 2020, 11:52 AM · Restricted Project
dexonsmith added a comment to D74984: [ADT] Add CoalescingBitVector, implemented using IntervalMap [1/3].

Is there any kind of "These are the ADT types in LLVM and when to use them" .rst document that this should be added to?

Feb 24 2020, 9:35 AM · debug-info, Restricted Project

Feb 20 2020

dexonsmith accepted D74939: clang/Modules: Finish renaming CompilerInstance::ModuleManager, NFC..

Thanks! LGTM. Don't know how I missed that API...

Feb 20 2020, 6:06 PM · Restricted Project

Feb 19 2020

dexonsmith added a comment to D69471: [Coverage] Revise format to reduce binary size.
In D69471#1883912, @rnk wrote:

Everything is off-by-one because the empty bases are not zero sized. The MSVC record layout algorithm is just different in this area. =/

Feb 19 2020, 7:20 PM · Restricted Project, Restricted Project, Restricted Project
dexonsmith added a comment to D74813: [RFC] Add hash of block contents to function block names.

Thanks for working on this, I agree it's a really important problem.

Feb 19 2020, 2:00 PM · Restricted Project

Feb 18 2020

dexonsmith added a comment to D74795: Make diagnostic reporting more robust in presence of corrupt PCH data..

Thanks for working on this! I have a couple of comments inline.

Feb 18 2020, 2:53 PM · Restricted Project
dexonsmith added a comment to D74784: [driver][darwin] Don't use -platform_version flag by default.

Code change looks correct to me. Thanks for the fix!

Feb 18 2020, 12:54 PM · Restricted Project, Restricted Project

Feb 14 2020

dexonsmith added a comment to D51664: [IR] Lazily number instructions for local dominance queries.
In D51664#1877029, @rnk wrote:

I still think we should do this. I think @fhahn is reimplementing DSE using MemorySSA, so presumably the DSE cases won't be an issue soon, but setting all that aside, I still think it would be nice if we could say once and for all that Instruction::dominates(Instruction*) is amortized O(1) if you haven't modified the instruction stream. Otherwise this kind of pathology will pop up again. Putting the ordering on the IR saves clients from ferrying around and maintaining OrderedInstructions / OrderedBasicBlock data structures, and that seems like a win.

Feb 14 2020, 1:07 PM · Restricted Project

Feb 10 2020

dexonsmith added a comment to D74341: [libc++][Apple] Use CLOCK_MONOTONIC_RAW instead of CLOCK_UPTIME_RAW for steady_clock.

Specifically, I'm looking to understand why Eric's comment at that time (https://reviews.llvm.org/D27429#618296) about using CLOCK_MONOTONIC_RAW wasn't acted upon -- did we simply overlook it or is there a reason why CLOCK_MONOTONIC_RAW is not a suitable implementation?

Feb 10 2020, 10:18 AM · Restricted Project

Feb 7 2020

dexonsmith added inline comments to D74183: [IRGen] Add an alignment attribute to underaligned sret parameters.
Feb 7 2020, 11:03 AM · Restricted Project
dexonsmith added inline comments to D74183: [IRGen] Add an alignment attribute to underaligned sret parameters.
Feb 7 2020, 10:35 AM · Restricted Project

Feb 5 2020

dexonsmith accepted D74062: [ADT] Fix iplist_impl - use after move warnings (PR43943).

LGTM. Thanks for the fix!

Feb 5 2020, 10:52 AM · Restricted Project

Jan 30 2020

dexonsmith accepted D73208: [objc_direct] fix codegen for mismatched Decl/Impl return types.

LGTM, with one style nitpick.

Jan 30 2020, 5:18 PM · Restricted Project
dexonsmith added a comment to D73208: [objc_direct] fix codegen for mismatched Decl/Impl return types.

I think we're talking across each other. The idea is check the type when generating the implementation; if it's not correct, you fix it (need to update existing uses to bitcast). So the type used for the implementation would match dynamic methods.

ah I see, I don't know how to do that, I couldn't figure out how to fix the function declaration, if you want to give it a stab I'd love it.

Jan 30 2020, 12:57 PM · Restricted Project

Jan 28 2020

dexonsmith accepted D73500: [driver] Add a -builtininc flag that lets Darwin driver include Clang builtin headers even with -nostdinc.

Okay, LGTM.

Jan 28 2020, 5:46 PM · Restricted Project

Jan 27 2020

dexonsmith requested changes to D73500: [driver] Add a -builtininc flag that lets Darwin driver include Clang builtin headers even with -nostdinc.
Jan 27 2020, 2:43 PM · Restricted Project

Jan 24 2020

dexonsmith closed D72970: clang: Only define OBJC_NEW_PROPERTIES when -x objective-c.

Thanks, committed in 1e487e4c16821b6de3d651f618274df90bd3fad9.

Jan 24 2020, 2:56 PM
dexonsmith committed rG1e487e4c1682: clang: Only define OBJC_NEW_PROPERTIES when -x objective-c (authored by dexonsmith).
clang: Only define OBJC_NEW_PROPERTIES when -x objective-c
Jan 24 2020, 2:56 PM

Jan 23 2020

dexonsmith added a comment to D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer..

@rsmith This also breaks macOS SDK. Can we revert this as we discuss a less aggressive option?

Do you have a timeline for how long it would take to fix the MacOS SDK? Is this something we could realistically aim to do in Clang 11 instead? I would really prefer for us to not have different defaults for Darwin versus everywhere else, so if waiting one release cycle is enough, that seems fine.

I am also not sure if we have rules about SDK compatibility for releases and I can't say macOS SDK can definitely be fixed before clang 11 release. @dexonsmith @arphaman might have more info.

We can't comment on future releases.

That said, if this is urgent, let @arphaman know and we can try to qualify internally sometime in the next few months and we can report back what issues we find.

Understood. The current situation is deeply unpalatable (the conversions we allow by default that this patch would have disabled are *evil* and have never been supported by GCC; it looks like Clang only ever allowed them as a bug, and we really need to turn them off by default for safety as much as for GCC compatibility). But this isn't a regression, at least, so I don't think this is especially urgent. (I was working on this because Agner Fog made an impassioned plea that we fix this, and I think our community owes Agner a favor or two...)

Jan 23 2020, 12:36 PM · Restricted Project
dexonsmith added a comment to D73208: [objc_direct] fix codegen for mismatched Decl/Impl return types.

Why isn't a similar dance needed for non-direct methods?

because non direct methods do not need an llvm::Function to be synthesized at the call-site. direct methods do, and they form one with the type of the declaration they see. Then that same llvm::Function is used when you CodeGen the Implementation, so if there's a mismatch, sadness ensues because the LLVM IR verifier will notice the discrepancy between the declared return type of the function and the actual types coming out of the ret codepaths.

Regular obj-C methods use the _implementation_ types for the codegen (the declaration(s) aren't even consulted) and I want to stick at what obj-c does as much as I can.

(as a data point: If you use obj-C types with C functions, the type of the first declaration seen is used instead).

Okay, that makes sense to me.

Another solution would be to change IRGen for the implementation: if the declaration already exists (getFunction), do a bitcast + RAUW dance to fix it up (and update the DirectMethodDefinitions table). WDYT?

I didn't want to do that because that would mean that the type used for the implementation would depart from dynamic Objective-C methods, and it feels that it shouldn't. hence I took this option.

Jan 23 2020, 11:14 AM · Restricted Project
dexonsmith added a comment to D73208: [objc_direct] fix codegen for mismatched Decl/Impl return types.

Why isn't a similar dance needed for non-direct methods?

because non direct methods do not need an llvm::Function to be synthesized at the call-site. direct methods do, and they form one with the type of the declaration they see. Then that same llvm::Function is used when you CodeGen the Implementation, so if there's a mismatch, sadness ensues because the LLVM IR verifier will notice the discrepancy between the declared return type of the function and the actual types coming out of the ret codepaths.

Regular obj-C methods use the _implementation_ types for the codegen (the declaration(s) aren't even consulted) and I want to stick at what obj-c does as much as I can.

(as a data point: If you use obj-C types with C functions, the type of the first declaration seen is used instead).

Jan 23 2020, 10:39 AM · Restricted Project
dexonsmith added a comment to D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer..

@rsmith This also breaks macOS SDK. Can we revert this as we discuss a less aggressive option?

Do you have a timeline for how long it would take to fix the MacOS SDK? Is this something we could realistically aim to do in Clang 11 instead? I would really prefer for us to not have different defaults for Darwin versus everywhere else, so if waiting one release cycle is enough, that seems fine.

I am also not sure if we have rules about SDK compatibility for releases and I can't say macOS SDK can definitely be fixed before clang 11 release. @dexonsmith @arphaman might have more info.

Jan 23 2020, 10:27 AM · Restricted Project
dexonsmith accepted D73219: [objc_direct] do not add direct properties to the serialization array.

LGTM.

Jan 23 2020, 9:15 AM · Restricted Project

Jan 22 2020

dexonsmith added a comment to D73208: [objc_direct] fix codegen for mismatched Decl/Impl return types.

Why isn't a similar dance needed for non-direct methods?

Jan 22 2020, 3:40 PM · Restricted Project
dexonsmith added inline comments to D73219: [objc_direct] do not add direct properties to the serialization array.
Jan 22 2020, 1:00 PM · Restricted Project

Jan 21 2020

dexonsmith removed reviewers for D68997: Allow searching for prebuilt implicit modules.: llvm-commits, cfe-commits.
Jan 21 2020, 3:37 PM · Restricted Project
dexonsmith added a reviewer for D68997: Allow searching for prebuilt implicit modules.: Bigcheese.
Jan 21 2020, 3:37 PM · Restricted Project
dexonsmith accepted D72708: [libc++] Make sure std::is_object returns true for block types.

This LGTM too, but like John I would prefer a non-_OBJC_ name for the macro since -fblocks also gets used with C/C++.

Jan 21 2020, 1:37 PM · Restricted Project

Jan 17 2020

dexonsmith created D72970: clang: Only define OBJC_NEW_PROPERTIES when -x objective-c.
Jan 17 2020, 5:42 PM

Jan 16 2020

dexonsmith accepted D72860: [modules] Do not cache invalid state for modules that we attempted to load..

LGTM.

Jan 16 2020, 12:28 PM · Restricted Project

Jan 15 2020

dexonsmith added a comment to D72399: [Support] Replace Windows __declspec(thread) with thread_local in LLVM_THREAD_LOCAL.
In D72399#1822902, @rnk wrote:

Honestly, if __thread is available, I wonder if LLVM should prefer that, since it implements the check that the variable is trivially constructible/destructible. But, that has no bearing on which declspec to use.

Is "trivially constructible/destructible" actually a requirement for this? I thought that restriction was due to host platforms which didn't support C++11 thread_local (hence if/when every platform supported C++11 thread_local then the restriction would go away).

Yes, LLVM still supports platforms which do not support C++11 thread_local, so for LLVM, there is still a requirement that things be trivially constructible/destructible. If we used __thread when available, the compiler would enforce that check earlier, rather than letting the contributor commit, push, and find out about this requirement from a buildbot.

Jan 15 2020, 3:15 PM · Restricted Project

Jan 9 2020

GitHub <noreply@github.com> committed rG2089a0d09bbc: Merge pull request #314 from dexonsmith/docs/apple-branching-scheme (authored by dexonsmith).
Merge pull request #314 from dexonsmith/docs/apple-branching-scheme
Jan 9 2020, 3:53 PM
dexonsmith committed rG752558d42de3: apple-docs: Document Apple's branching scheme (authored by dexonsmith).
apple-docs: Document Apple's branching scheme
Jan 9 2020, 3:53 PM

Dec 12 2019

GitHub <noreply@github.com> committed rG7cc97aaffc5d: Merge pull request #340 from dexonsmith/llvm/arc/cherry-pick-autoreleaserv… (authored by dexonsmith).
Merge pull request #340 from dexonsmith/llvm/arc/cherry-pick-autoreleaserv…
Dec 12 2019, 3:53 PM
dexonsmith committed rG5da777193445: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls (authored by dexonsmith).
llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls
Dec 12 2019, 3:53 PM
dexonsmith committed rG9eda4238fa28: llvm/ObjCARC: Split OptimizeIndividualCallImpl out of OptimizeIndividualCalls… (authored by dexonsmith).
llvm/ObjCARC: Split OptimizeIndividualCallImpl out of OptimizeIndividualCalls…
Dec 12 2019, 3:53 PM
dexonsmith committed rG669812befd5f: llvm/ObjCARC: Use continue to reduce some nesting, NFC (authored by dexonsmith).
llvm/ObjCARC: Use continue to reduce some nesting, NFC
Dec 12 2019, 3:53 PM
GitHub <noreply@github.com> committed rGd976623568b3: Merge pull request #328 from MadCoder/eng/PR-2684889-direct (authored by dexonsmith).
Merge pull request #328 from MadCoder/eng/PR-2684889-direct
Dec 12 2019, 3:53 PM
GitHub <noreply@github.com> committed rG7f22c4d4867f: Merge pull request #289 from dexonsmith/clang/Modules/20191106/cherry-picks-for… (authored by dexonsmith).
Merge pull request #289 from dexonsmith/clang/Modules/20191106/cherry-picks-for…
Dec 12 2019, 3:52 PM
dexonsmith committed rGdfb6397de0b8: clang/Modules: Error if ReadASTBlock does not find the main module (authored by dexonsmith).
clang/Modules: Error if ReadASTBlock does not find the main module
Dec 12 2019, 3:51 PM
dexonsmith committed rGd250fb8b68f5: clang/Modules: Clean up modules on error in ReadAST (authored by dexonsmith).
clang/Modules: Clean up modules on error in ReadAST
Dec 12 2019, 3:51 PM
dexonsmith committed rGeea0b7cfcc46: clang/Modules: Add missing diagnostics for malformed AST files (authored by dexonsmith).
clang/Modules: Add missing diagnostics for malformed AST files
Dec 12 2019, 3:51 PM
dexonsmith committed rG5a5a2980ec4c: clang/Modules: Split loop in ReadAST between failable and not (authored by dexonsmith).
clang/Modules: Split loop in ReadAST between failable and not
Dec 12 2019, 3:51 PM
dexonsmith committed rGa08033917c5d: clang/Modules: Use range-based for in ASTReader::ReadAST, NFC (authored by dexonsmith).
clang/Modules: Use range-based for in ASTReader::ReadAST, NFC
Dec 12 2019, 3:51 PM
dexonsmith committed rG9c772f2d7b7b: clang/Modules: Delay err_module_file_conflict if a diagnostic is in flight (authored by dexonsmith).
clang/Modules: Delay err_module_file_conflict if a diagnostic is in flight
Dec 12 2019, 3:51 PM
dexonsmith committed rG94f1f0a63411: clang/Modules: Remove unused parameter from ModuleManager::removeModules (authored by dexonsmith).
clang/Modules: Remove unused parameter from ModuleManager::removeModules
Dec 12 2019, 3:51 PM
dexonsmith committed rGd42237e35632: libc: Merge in missing content from 7b9fd37f (authored by dexonsmith).
libc: Merge in missing content from 7b9fd37f
Dec 12 2019, 3:02 PM
dexonsmith committed rGd9a81d068a1d: Merge remote-tracking branch 'llvm.org/master' into upstream-with-swift (authored by dexonsmith).
Merge remote-tracking branch 'llvm.org/master' into upstream-with-swift
Dec 12 2019, 1:09 PM

Dec 9 2019

dexonsmith added a comment to D71219: Fix conflict value for metadata "Objective-C Garbage Collection" in the mix of swift and Objective-C bitcode.

Yeah, the discussion Jin and I had privately was that we should split the Swift ABI version out of the ObjC GC global metadata and update the backend so that it assembles the image info appropriately from different places. I don't know what happened to that.

That will probably require an IR updater, but that shouldn't be a problem.

Dec 9 2019, 2:35 PM · Restricted Project, Restricted Project
dexonsmith added reviewers for D71219: Fix conflict value for metadata "Objective-C Garbage Collection" in the mix of swift and Objective-C bitcode: ahatanak, steven_wu.
Dec 9 2019, 2:01 PM · Restricted Project, Restricted Project

Dec 5 2019

dexonsmith added a comment to D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation.

I guess Duncan's comments on https://reviews.llvm.org/D70568 were for this patch. I think it would be good to have:

Dec 5 2019, 11:21 AM · Restricted Project, Restricted Project
dexonsmith added a comment to D70568: [Support] Possibly use exception handler in the Crash Recovery Context in the same way as global exceptions.
Dec 5 2019, 11:21 AM · Restricted Project, Restricted Project

Dec 3 2019

dexonsmith added a comment to D70568: [Support] Possibly use exception handler in the Crash Recovery Context in the same way as global exceptions.

Can we make this configurable somehow? (E.g., leave behind an -ffork-cc1 -fno-fork-cc1 and a CMake flag to pick? Or just the CMake flag?)

Dec 3 2019, 4:37 PM · Restricted Project, Restricted Project
dexonsmith added a comment to D70568: [Support] Possibly use exception handler in the Crash Recovery Context in the same way as global exceptions.

This is really cool; we've wanted this for a long time.

Dec 3 2019, 4:37 PM · Restricted Project, Restricted Project

Dec 2 2019

dexonsmith accepted D70936: [clang-scan-deps] do not skip empty #if/#elif in the minimize to avoid missing `__has_include` dependencies.

LGTM, although I have a suggested change for one of the comments (and I'm still sad about this).

Dec 2 2019, 6:24 PM · Restricted Project

Nov 22 2019

dexonsmith committed rG20d51b2f14ac: clang/Modules: Rename CompilerInstance::ModuleManager, NFC (authored by dexonsmith).
clang/Modules: Rename CompilerInstance::ModuleManager, NFC
Nov 22 2019, 6:31 PM
dexonsmith closed D70583: clang/Modules: Rename CompilerInstance::ModuleManager, NFC.

Pushed as 20d51b2f14ac4488f684f8fc57cb0ba718a6b91d.

Nov 22 2019, 6:31 PM
dexonsmith committed rG5cca622310c1: clang/Modules: Refactor CompilerInstance::loadModule, NFC (authored by dexonsmith).
clang/Modules: Refactor CompilerInstance::loadModule, NFC
Nov 22 2019, 6:27 PM
dexonsmith closed D70556: clang/Modules: Refactor CompilerInstance::loadModule, NFC.

Pushed as 20d51b2f14ac4488f684f8fc57cb0ba718a6b91d.

Nov 22 2019, 6:27 PM

Nov 21 2019

dexonsmith committed rGf7170d17a846: clang/Modules: Move Serialization/Module.{h,cpp} to ModuleFile, NFC (authored by dexonsmith).
clang/Modules: Move Serialization/Module.{h,cpp} to ModuleFile, NFC
Nov 21 2019, 7:12 PM
dexonsmith added a parent revision for D70583: clang/Modules: Rename CompilerInstance::ModuleManager, NFC: D70556: clang/Modules: Refactor CompilerInstance::loadModule, NFC.
Nov 21 2019, 6:45 PM
dexonsmith added a child revision for D70556: clang/Modules: Refactor CompilerInstance::loadModule, NFC: D70583: clang/Modules: Rename CompilerInstance::ModuleManager, NFC.
Nov 21 2019, 6:45 PM
dexonsmith created D70583: clang/Modules: Rename CompilerInstance::ModuleManager, NFC.
Nov 21 2019, 6:45 PM
dexonsmith added inline comments to D70556: clang/Modules: Refactor CompilerInstance::loadModule, NFC.
Nov 21 2019, 2:39 PM
dexonsmith added inline comments to D70556: clang/Modules: Refactor CompilerInstance::loadModule, NFC.
Nov 21 2019, 12:22 PM
dexonsmith created D70556: clang/Modules: Refactor CompilerInstance::loadModule, NFC.
Nov 21 2019, 12:13 PM

Nov 19 2019

dexonsmith committed rG870083173481: clang/Modules: Early return in CompilerInstance::createModuleManager, NFC (authored by dexonsmith).
clang/Modules: Early return in CompilerInstance::createModuleManager, NFC
Nov 19 2019, 6:23 PM
dexonsmith added a comment to D70284: Constant strings emitted when `-fno-constant-cfstrings` is passed should allow dead stripping.

For some reason this revision is locked down and I'm not allowed to "edit" it, which includes adding inline review comments. Can you add me as a reviewer?

Nov 19 2019, 6:05 PM · Restricted Project
dexonsmith committed rG69242e986823: clang/Modules: Sink ASTReadResult in ReadControlBlock, NFC (authored by dexonsmith).
clang/Modules: Sink ASTReadResult in ReadControlBlock, NFC
Nov 19 2019, 4:14 PM
dexonsmith committed rG8c4840506908: Wrap C APIs with pragmas enforcing -Werror=strict-prototypes (authored by dexonsmith).
Wrap C APIs with pragmas enforcing -Werror=strict-prototypes
Nov 19 2019, 1:20 PM
dexonsmith closed D70285: Wrap C APIs with pragmas enforcing -Werror=strict-prototypes.

lgtm as long as other compilers don't warn on unknown pragmas by default.

godbolt.org says that GCC doesn't have -Wunknown-pragmas by default, but it is in -Wall. I'd better guard this more closely with __clang__.

Nov 19 2019, 1:20 PM · Restricted Project
dexonsmith added a comment to D70285: Wrap C APIs with pragmas enforcing -Werror=strict-prototypes.

lgtm as long as other compilers don't warn on unknown pragmas by default.

Nov 19 2019, 1:01 PM · Restricted Project
dexonsmith committed rG3279724905c1: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls (authored by dexonsmith).
llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls
Nov 19 2019, 12:06 PM
dexonsmith closed D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.

Pushed as 3279724905c14a8db383ade53af40a0dd49504d8.

Nov 19 2019, 12:06 PM · Restricted Project
dexonsmith accepted D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.

@rjmccall gave me an LGTM offline.

Nov 19 2019, 12:06 PM · Restricted Project

Nov 18 2019

dexonsmith updated the diff for D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.

It wasn't clear to me, but is the pair deleted only if there are no instructions that return false for isSafeBetweenRVCalls in between?

I thought it was okay to skip over all opaque calls, but I've changed the code to check for this.

Nov 18 2019, 6:53 PM · Restricted Project
dexonsmith updated the diff for D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.

Respond to Akira's feedback.

Nov 18 2019, 2:01 PM · Restricted Project