Page MenuHomePhabricator

danzimm (Dan Zimmerman)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 9 2017, 1:31 PM (121 w, 2 d)

Recent Activity

Mar 28 2019

danzimm added a comment to D59873: Add additional mangling for struct members of non trivial structs.

@smeenai good idea on the third level!

Mar 28 2019, 9:07 AM · Restricted Project, Restricted Project
danzimm updated the diff for D59873: Add additional mangling for struct members of non trivial structs.

Add a third level to ensure nontrivial structs within structs within structs works (this suggests that N embeddings works too). Also change the invocation of the test

Mar 28 2019, 9:05 AM · Restricted Project, Restricted Project

Mar 27 2019

danzimm added a comment to D59873: Add additional mangling for struct members of non trivial structs.

@smeenai please feel free add any reviewers that I might've missed

Mar 27 2019, 6:37 AM · Restricted Project, Restricted Project
danzimm added reviewers for D59873: Add additional mangling for struct members of non trivial structs: rjmccall, ahatanak.
Mar 27 2019, 6:37 AM · Restricted Project, Restricted Project
danzimm updated the diff for D59873: Add additional mangling for struct members of non trivial structs.

I forgot to add the test originally, this update contains a test and updates to old tests to make them pass

Mar 27 2019, 6:34 AM · Restricted Project, Restricted Project
danzimm added a comment to D59873: Add additional mangling for struct members of non trivial structs.

@lebedev.ri right, sorry about that- I prematurely diff'd (got a few terminals crossed and thought I was finished with the test already). I will be amending with a test and a few other test fixes shortly. Sorry about the miscommunication :/

Mar 27 2019, 6:06 AM · Restricted Project, Restricted Project
danzimm updated the summary of D59873: Add additional mangling for struct members of non trivial structs.
Mar 27 2019, 6:06 AM · Restricted Project, Restricted Project
danzimm created D59873: Add additional mangling for struct members of non trivial structs.
Mar 27 2019, 5:47 AM · Restricted Project, Restricted Project

Oct 1 2018

danzimm added a comment to D52664: Update CMakeLists.txt snippet so that example compiles.

@steveire can you land this for me? I don't have commit access

Oct 1 2018, 7:59 AM

Sep 28 2018

danzimm created D52664: Update CMakeLists.txt snippet so that example compiles.
Sep 28 2018, 11:26 AM

Dec 14 2017

danzimm added a comment to D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

Also, I don't have commit access. Could someone else commit this for me?

Dec 14 2017, 7:00 AM
danzimm added a comment to D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

@dexonsmith Here are my results after passing those extra flags with -O3 (/Users/danzimm/oss/build/bin/clang -cc1 -internal-isystem /Users/danzimm/oss/build/lib/clang/6.0.0/include -nostdsysteminc -triple x86_64-apple-macosx10.12.0 -emit-llvm -disable-llvm-passes -O3 -fblocks -fobjc-arc -fobjc-runtime-has-weak -std=c++11 -mllvm -debug-pass=Executions -o ~/foo.ll /Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm):

Pass Arguments:  -tti
Target Transform Information
  FunctionPass Manager
Pass Arguments:  -tti
Target Transform Information
  ModulePass Manager
    Print Module IR
[2017-12-14 09:47:12.252472000] 0x7f87b90016f0   Executing Pass 'Print Module IR' on Module '/Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm'...
[2017-12-14 09:47:12.254702000] 0x7f87b90016f0    Freeing Pass 'Print Module IR' on Module '/Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm'...
Pass Arguments:  -tti
Target Transform Information
  ModulePass Manager

and with -O0 (/Users/danzimm/oss/build/bin/clang -cc1 -internal-isystem /Users/danzimm/oss/build/lib/clang/6.0.0/include -nostdsysteminc -triple x86_64-apple-macosx10.12.0 -emit-llvm -disable-llvm-passes -O0 -fblocks -fobjc-arc -fobjc-runtime-has-weak -std=c++11 -mllvm -debug-pass=Executions -o ~/foo.ll /Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm):

Pass Arguments:  -tti
Target Transform Information
  FunctionPass Manager
Pass Arguments:  -tti
Target Transform Information
  ModulePass Manager
    Print Module IR
[2017-12-14 09:47:20.884147000] 0x7ff71ed097d0   Executing Pass 'Print Module IR' on Module '/Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm'...
[2017-12-14 09:47:20.886182000] 0x7ff71ed097d0    Freeing Pass 'Print Module IR' on Module '/Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm'...
Pass Arguments:  -tti
Target Transform Information
  ModulePass Manager
Dec 14 2017, 6:50 AM

Dec 13 2017

danzimm updated the diff for D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

Remove unnecessary checks from tests (sorry for unbatched updates)

Dec 13 2017, 8:24 PM
danzimm updated the diff for D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

Pass -disable-llvm-passes with -O3 so that we can test that the IR we generate actually is generated

Dec 13 2017, 8:20 PM
danzimm added a comment to D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

I just dug into how the ARC optimization pass is invoked... it really shouldn't be invoked if -disable-llvm-passes is passed (or -disable-llvm-optzns which appears to just alias the first). Can you verify that my command is sane:

Dec 13 2017, 7:16 PM
danzimm added a comment to D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

Change tests to use non-O2 generated IR. It looks like the combined objc_retainAutoreleasedReturnValue/objc_autoreleaseReturnValue calls annihilate each other and we just get a call/ret.

Is that really happening at -O0? Maybe you need to add -disable-llvm-optzns to the test line if so.

Dec 13 2017, 5:56 PM
danzimm added a comment to D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

Ah, just found test/Transforms/ObjCARC/rv.ll test3:

; Delete a redundant retainRV,autoreleaseRV when forwaring a call result
; directly to a return value.
Dec 13 2017, 8:58 AM
danzimm updated the diff for D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

Change tests to use non-O2 generated IR. It looks like the combined objc_retainAutoreleasedReturnValue/objc_autoreleaseReturnValue calls annihilate each other and we just get a call/ret.

Dec 13 2017, 7:48 AM

Dec 12 2017

danzimm retitled D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer from Fix over-release of return value of lambda implicitly converted to block to Fix over-release of return value of lambda implicitly converted to block/function pointer.
Dec 12 2017, 2:49 PM
danzimm updated the diff for D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

Remove unnecessary change of braces

Dec 12 2017, 2:35 PM
danzimm added a comment to D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

@rjmccall aha, right - thanks for explaining that to me (sorry for the bad logic I had earlier).

Dec 12 2017, 2:33 PM
danzimm updated the summary of D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.
Dec 12 2017, 2:30 PM
danzimm updated the diff for D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

Call objc_retainAutoreleasedReturnValue after invoking a wrapped lambda

Dec 12 2017, 2:28 PM
danzimm added a comment to D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

Or do we need to abide by those semantics strictly here? Could you expand on why that is, if that's the case?

Dec 12 2017, 11:52 AM
danzimm added a comment to D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.

@rjmccall ah right, good point -- I think it's ok to elide that objc_retainAutoreleasedReturnValue/objc_autoreleaseReturnValue pair in this case though, since all of this is generated within clang itself (and thus we can make the guarentee that the object will properly live until the return of the enclosing block) -- it reduces retain count churn this way too

Dec 12 2017, 11:51 AM

Dec 9 2017

danzimm created D41050: Fix over-release of return value of lambda implicitly converted to block/function pointer.
Dec 9 2017, 1:41 PM