Page MenuHomePhabricator
Feed Advanced Search

Today

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.

Mon, Feb 24, 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?

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

Thu, Feb 20

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

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

Thu, Feb 20, 6:06 PM · Restricted Project

Wed, Feb 19

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. =/

Wed, Feb 19, 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.

Wed, Feb 19, 2:00 PM · Restricted Project

Tue, Feb 18

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.

Tue, Feb 18, 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!

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

Fri, Feb 14

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.

Fri, Feb 14, 1:07 PM · Restricted Project

Mon, Feb 10

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?

Mon, Feb 10, 10:18 AM · Restricted Project

Fri, Feb 7

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

Wed, Feb 5

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

LGTM. Thanks for the fix!

Wed, Feb 5, 10:52 AM · Restricted Project

Thu, Jan 30

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

LGTM, with one style nitpick.

Thu, Jan 30, 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.

Thu, Jan 30, 12:57 PM · Restricted Project

Tue, Jan 28

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

Okay, LGTM.

Tue, Jan 28, 5:46 PM · Restricted Project

Mon, Jan 27

dexonsmith requested changes to D73500: [driver] Add a -builtininc flag that lets Darwin driver include Clang builtin headers even with -nostdinc.
Mon, Jan 27, 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
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

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
dexonsmith added a comment to 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?

Nov 18 2019, 2:01 PM · Restricted Project
dexonsmith committed rGd4e1ba3fa9df: Implement __attribute__((objc_direct)), __attribute__((objc_direct_members)) (authored by MadCoder).
Implement __attribute__((objc_direct)), __attribute__((objc_direct_members))
Nov 18 2019, 11:54 AM
dexonsmith closed D69991: Implement __attribute__((objc_direct)), __attribute__((objc_direct_members)).

Pushed as d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1.

Nov 18 2019, 11:53 AM · Restricted Project
dexonsmith added inline comments to D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.
Nov 18 2019, 11:26 AM · Restricted Project
dexonsmith updated the diff for D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.

Adding more testcases. The bitcast tests uncovered problems with the RAUW calls, which I also fixed.

Nov 18 2019, 11:26 AM · Restricted Project

Nov 17 2019

dexonsmith added inline comments to D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.
Nov 17 2019, 10:11 PM · Restricted Project
dexonsmith closed D70369: llvm/ObjCARC: Split OptimizeIndividualCallImpl out of OptimizeIndividualCalls, NFC.

Committed in 783cb86b616d9de59213ea17649d6e2df8c1ebbb.

Nov 17 2019, 10:08 PM · Restricted Project
dexonsmith updated the diff for D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.

Added an assertion for clarity and fixed a comment.

Nov 17 2019, 10:08 PM · Restricted Project
dexonsmith committed rG783cb86b616d: llvm/ObjCARC: Split OptimizeIndividualCallImpl out of OptimizeIndividualCalls… (authored by dexonsmith).
llvm/ObjCARC: Split OptimizeIndividualCallImpl out of OptimizeIndividualCalls…
Nov 17 2019, 10:03 PM
dexonsmith added a parent revision for D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls: D70369: llvm/ObjCARC: Split OptimizeIndividualCallImpl out of OptimizeIndividualCalls, NFC.
Nov 17 2019, 8:00 PM · Restricted Project
dexonsmith added a child revision for D70369: llvm/ObjCARC: Split OptimizeIndividualCallImpl out of OptimizeIndividualCalls, NFC: D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.
Nov 17 2019, 8:00 PM · Restricted Project
dexonsmith created D70369: llvm/ObjCARC: Split OptimizeIndividualCallImpl out of OptimizeIndividualCalls, NFC.
Nov 17 2019, 8:00 PM · Restricted Project
dexonsmith created D70370: llvm/ObjCARC: Eliminate inlined AutoreleaseRV calls.
Nov 17 2019, 8:00 PM · Restricted Project
dexonsmith committed rGa937a588dd29: llvm/ObjCARC: Use continue to reduce some nesting, NFC (authored by dexonsmith).
llvm/ObjCARC: Use continue to reduce some nesting, NFC
Nov 17 2019, 6:23 PM

Nov 15 2019

dexonsmith updated the diff for D70285: Wrap C APIs with pragmas enforcing -Werror=strict-prototypes.

s/C_STRING_PROTOTYPES_/C_STRICT_PROTOTYPES_/ to fix some typos.

Nov 15 2019, 1:21 PM · Restricted Project
dexonsmith added inline comments to D70285: Wrap C APIs with pragmas enforcing -Werror=strict-prototypes.
Nov 15 2019, 1:12 PM · Restricted Project
dexonsmith updated the diff for D70285: Wrap C APIs with pragmas enforcing -Werror=strict-prototypes.

Adding guards for _MSC_VER.

Nov 15 2019, 1:12 PM · Restricted Project

Nov 14 2019

dexonsmith added a comment to D70285: Wrap C APIs with pragmas enforcing -Werror=strict-prototypes.

Note that we have C files including these headers in llvm/tools/llvm-c-test and clang/tools/c-index-test, and I tested that dropping a (void) to just () triggers the error when compiling those.

Nov 14 2019, 6:26 PM · Restricted Project
dexonsmith added a comment to D70284: Constant strings emitted when `-fno-constant-cfstrings` is passed should allow dead stripping.

The code looks right, but can you add a test for this in CodeGenObjC? Also, when you re-upload the patch with the tests, please use -U9999999 to provide full context in the diff.

Nov 14 2019, 6:08 PM · Restricted Project
dexonsmith created D70285: Wrap C APIs with pragmas enforcing -Werror=strict-prototypes.
Nov 14 2019, 5:58 PM · Restricted Project
dexonsmith requested changes to D11833: s/NDEBUG/LLVM_NDEBUG/ in most places.

Stepping back to look at the goals:

Nov 14 2019, 11:48 AM
dexonsmith added inline comments to D69991: Implement __attribute__((objc_direct)), __attribute__((objc_direct_members)).
Nov 14 2019, 10:06 AM · Restricted Project

Nov 13 2019

dexonsmith added a comment to D11833: s/NDEBUG/LLVM_NDEBUG/ in most places.

OK but these NDEBUG aren't necessarily harmful, are they?

IIRC we added LLVM_ENABLE_ABI_BREAKING_CHECKS to cover the cases because previous using NDEBUG in the client was *required* to match the settings at the time LLVM was built.

Nov 13 2019, 1:56 PM