- User Since
- Dec 4 2013, 1:37 PM (384 w, 2 h)
Tue, Apr 6
LGTM, but you can wait for the final approval from @aprantl.
Thu, Apr 1
I agree with you. If it's not going to work, maybe there should have been a warning.
Wed, Mar 31
I see a warning when I compile the following (contrived) example:
Mon, Mar 22
Mar 9 2021
Moved the header back in dca5737945b9a52d0c66c7ec0cbaa2e15ada69cf
Mar 8 2021
I'll move the header back to Analysis.
Mar 4 2021
Thanks! Reapplied the patch in https://github.com/llvm/llvm-project/commit/1900503595cbb84a4c6e140a9ba1a2c574c0586d
Mar 3 2021
Emit a call to @llvm.objc.retain instead of a call to @llvm.objc.retainAutoreleasedReturnValue.
On second thought, I think we should emit a call to @llvm.objc.retain instead of a call to @llvm.objc.retainAutoreleasedReturnValue. I think we might want to remove ARC optimizer's code that converts calls to @llvm.objc.retainAutoreleasedReturnValue to calls to @llvm.objc.retain since it sometimes does the transformation when it shouldn't and we won't need that transformation once we switch to using the clang.arc.attachedcall operand bundle.
Mar 2 2021
We could emit a call to @llvm.objc.retain instead of the call to @llvm.objc.retainAutoreleasedReturnValue, but this doesn't seem to happen often and ARC optimizer can remove or replace the call anyway, so I'm just letting the front-end emit @llvm.objc.retainAutoreleasedReturnValue for simplicity.
Feb 28 2021
Feb 25 2021
Feb 22 2021
I managed to reproduce the failure by building everything with -DLLVM_APPEND_VC_REV=NO.
Feb 18 2021
OK, I se the other patch is using the bit.
VarDecl has a bit (EscapingByref) that indicates whether the __block variable is captured by an escaping block. Can that information be used to avoid pre-moving to the heap?
I still don't understand why the test was failing, but did we have to bump the version because a new LangOpt (EncodeCXXClassTemplateSpec) was added?
- Use BoolFOption to define both the positive and negative options.
- Enable the optimization if the ObjC runtime is a NeXT-family runtime.
Feb 17 2021
Add test cases for nested class.
Upload patch with context.
Enable this optimization only on Darwin.
Feb 16 2021
This patch focuses only on reducing the encoded size of classes with template specialization, but if the information about pointed-to types isn't used at all, clang can always emit "^v" for C++ pointer types. Or it might make more sense to base the decision on whether the type is POD rather than on whether the string includes template specialization.
Feb 15 2021
Feb 12 2021
Thanks! I didn't realize it hadn't been fixed in the patch I committed.
Feb 11 2021
- Renamed the operand bundle name to clang.arc.attachedcall. I also tried to pass the address of the ARC function as the argument, but the verifier doesn't allow taking addresses of intrinsics.
Address all review comments except for the ones about the bundle name.
Feb 10 2021
Fix two bugs which were discovered.
Feb 9 2021
This patch causes opt to crash when the following IR is compiled:
It looks like there is a pre-existing bug in replaceUsesOfNonProtoConstant where the operand bundles of all call sites are accumulated into newBundles. This will be fixed if its declaration is moved into the loop body. Also, we found another case of deadargelim changing the return type of the called function to void. I'll post a new patch when I have the fixes.
Feb 8 2021
I do have a plan to modify the auto upgrader to use the bundles when it's possible to do so, but I'm currently not considering landing the changes I reverted since they were only needed to avoid duplicating constant strings. I don't think we can avoid duplicating the string unless objcarc::getRVMarkerModuleFlagStr() can be moved to a file in llvm/include/llvm/IR.
Feb 5 2021
I ended up reverting the changes I made to llvm/lib/IR/AutoUpgrade.cpp as the file was including llvm/Analysis/ObjCARCUtil.h, which was violating layering.
Feb 3 2021
Make the alignment 16 bytes on 32-bit systems too.
Feb 2 2021
Add a description of the new bundle to LangRef.
Address review comments.
Feb 1 2021
We could run another pass to clean up the IR after inlining, but I think it's better to do the cleanup right after the callee function is cloned in the caller function.
Address review comments.
Jan 28 2021
Teach markTails to ignore operand bundle clang.arc.rv when determining whether a call can be marked as tail. ObjCARCOpt::OptimizeReturn cannot eliminate the retainRV/autoreleaseRV pair if the call isn't marked as tail.
Jan 27 2021
Address post-commit review comments.
Jan 26 2021
Jan 25 2021
Jan 22 2021
Stop using clang.arc.rv_marker and just use "clang.arc.rv"="retain/claim".
Jan 21 2021
Add a test for invoke and a FIXME for eliminating the need for emitARCOperationAfterCall.
Add helper functions to ObjCARCRVAttr.h for adding, removing, or looking up attributes.
Jan 19 2021
Jan 12 2021
Jan 11 2021
Rebase and fix a few bugs in the patch.
Jan 8 2021
OK, I see.
LGTM. ARC contract pass isn't being run by the NPM, but you are going to change that in the future, I guess?
Jan 7 2021
Is this change safe considering calls to EP.get() can add function declarations to the module as you mentioned in https://reviews.llvm.org/D86178?
Dec 28 2020
Make isParamDestroyedInCallee a method of ParmVarDecl.
Dec 18 2020
We could probably do something like what this patch is doing and determine whether a class can be passed in registers based on whether its subobjects can be passed in registers. If all of the subobjects can be passed in registers, the current class can be passed in registers too unless something declared in the current class forces it to be passed indirectly (e.g., a virtual function is declared).
This latest patch changes the way D is passed in the following example, which doesn't use trivial_abi at all:
Dec 16 2020
Dec 14 2020
Set the insert point before generating new instructions in insertRetainOrClaimRVCalls.
Dec 10 2020
Dec 9 2020
Rebase and ping.
Elaborate on when createCallInstWithColors should be called.
ToT clang/llvm (without this patch) is turning the call to @objc_unsafeClaimAutoreleasedReturnValue in the EH cleanup block into an unreachable when compiling the following code. It looks like this happens because the inliner isn't adding the funclet token, but it's not clear to me whether this is a bug or not.
Enable the optimization on Windows.
Hmm, it seems that calls to some of the ARC runtime functions don't get the token. In some cases, I'm seeing WinEHPrepare (ToT clang, without this patch) turn a call to @objc_unsafeClaimAutoreleasedReturnValue in an EH cleanup block into an unreachable.