danzimm added a comment.
@smeenai good idea on the third level!
Yep, I'll need somebody to commit this for me, thanks!
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59873/new/
https://reviews.llvm.org/D59873
danzimm added a comment.
@smeenai please feel free add any reviewers that I might've missed
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59873/new/
https://reviews.llvm.org/D59873
___
cfe-commits
danzimm updated this revision to Diff 192436.
danzimm added a comment.
I forgot to add the test originally, this update contains a test and updates to
old tests to make them pass
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59873/new/
danzimm added a comment.
@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 :/
Repository:
rG LLVM
danzimm created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
In https://bugs.llvm.org/show_bug.cgi?id=41206 we observe bad codegen when
embedding a non-trivial C struct within a C struct. This is due to the fact
that name mangling for non-trivial structs
danzimm added a comment.
@steveire can you land this for me? I don't have commit access
Repository:
rC Clang
https://reviews.llvm.org/D52664
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
danzimm created this revision.
danzimm added a reviewer: modocache.
Herald added a subscriber: cfe-commits.
Previous to this the example didn't work out of the box, it seems some cmake
config changed between when this was written and now.
Repository:
rC Clang
https://reviews.llvm.org/D52664
danzimm added a comment.
Also, I don't have commit access. Could someone else commit this for me?
Repository:
rC Clang
https://reviews.llvm.org/D41050
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
danzimm added a comment.
@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
danzimm updated this revision to Diff 126893.
danzimm added a comment.
Remove unnecessary checks from tests (sorry for unbatched updates)
Repository:
rC Clang
https://reviews.llvm.org/D41050
Files:
lib/CodeGen/CGClass.cpp
test/CodeGenObjCXX/arc-forwarded-lambda-call.mm
Index:
danzimm updated this revision to Diff 126892.
danzimm added a comment.
Pass -disable-llvm-passes with -O3 so that we can test that the IR we generate
actually is generated
Repository:
rC Clang
https://reviews.llvm.org/D41050
Files:
lib/CodeGen/CGClass.cpp
danzimm added a comment.
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:
danzimm added a comment.
In https://reviews.llvm.org/D41050#954668, @rjmccall wrote:
> In https://reviews.llvm.org/D41050#953917, @danzimm wrote:
>
> > Change tests to use non-O2 generated IR. It looks like the combined
> > objc_retainAutoreleasedReturnValue/objc_autoreleaseReturnValue calls
>
danzimm added a comment.
Ah, just found test/Transforms/ObjCARC/rv.ll test3:
; Delete a redundant retainRV,autoreleaseRV when forwaring a call result
; directly to a return value.
; CHECK-LABEL: define i8* @test3(
; CHECK: call i8* @returner()
; CHECK-NEXT: ret i8* %call
define
danzimm updated this revision to Diff 126763.
danzimm added a comment.
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.
Repository:
rC Clang
danzimm updated this revision to Diff 126633.
danzimm added a comment.
Remove unnecessary change of braces
Repository:
rC Clang
https://reviews.llvm.org/D41050
Files:
lib/CodeGen/CGClass.cpp
test/CodeGenObjCXX/arc-forwarded-lambda-call.mm
Index:
danzimm added a comment.
@rjmccall aha, right - thanks for explaining that to me (sorry for the bad
logic I had earlier).
It turns out this was also broken for a lambda that was auto-converted to a
function pointer who returned an ObjC object. I changed the test case to
reflect the more
danzimm updated this revision to Diff 126628.
danzimm added a comment.
Call objc_retainAutoreleasedReturnValue after invoking a wrapped lambda
Repository:
rC Clang
https://reviews.llvm.org/D41050
Files:
lib/CodeGen/CGBlocks.cpp
lib/CodeGen/CGClass.cpp
danzimm added a comment.
Or do we need to abide by those semantics strictly here? Could you expand on
why that is, if that's the case?
Repository:
rC Clang
https://reviews.llvm.org/D41050
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
danzimm added a comment.
@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
danzimm created this revision.
Herald added subscribers: cfe-commits, kosarev.
Clang has a pretty cool feature right now that will allow you to use a lambda
as a block. Unfortunately there's a bug in this conversion if the return value
of the block is an ObjC object and arc is enabled -- the
21 matches
Mail list logo
