#
3fe3946d |
| 25-Jan-2021 |
Akira Hatanaka <ahatanaka@apple.com> |
[ObjC][ARC] Use operand bundle 'clang.arc.rv' instead of explicitly emitting retainRV or claimRV calls in the IR
Background:
This patch makes changes to the front-end and middle-end that are needed
[ObjC][ARC] Use operand bundle 'clang.arc.rv' instead of explicitly emitting retainRV or claimRV calls in the IR
Background:
This patch makes changes to the front-end and middle-end that are needed to fix a longstanding problem where llvm breaks ARC's autorelease optimization (see the link below) by separating calls from the marker instructions or retainRV/claimRV calls. The backend changes are in https://reviews.llvm.org/D92569.
https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-autoreleasereturnvalue
What this patch does to fix the problem:
- The front-end adds operand bundle "clang.arc.rv" to calls, which indicates the call is implicitly followed by a marker instruction and an implicit retainRV/claimRV call that consumes the call result. In addition, it emits a call to @llvm.objc.clang.arc.noop.use, which consumes the call result, to prevent the middle-end passes from changing the return type of the called function. This is currently done only when the target is arm64 and the optimization level is higher than -O0.
- ARC optimizer temporarily emits retainRV/claimRV calls after the calls with the operand bundle in the IR and removes the inserted calls after processing the function.
- ARC contract pass emits retainRV/claimRV calls after the call with the operand bundle. It doesn't remove the operand bundle on the call since the backend needs it to emit the marker instruction. The retainRV and claimRV calls are emitted late in the pipeline to prevent optimization passes from transforming the IR in a way that makes it harder for the ARC middle-end passes to figure out the def-use relationship between the call and the retainRV/claimRV calls (which is the cause of PR31925).
- The function inliner removes an autoreleaseRV call in the callee if nothing in the callee prevents it from being paired up with the retainRV/claimRV call in the caller. It then inserts a release call if the call is annotated with claimRV since autoreleaseRV+claimRV is equivalent to a release. If it cannot find an autoreleaseRV call, it tries to transfer the operand bundle to a function call in the callee. This is important since ARC optimizer can remove the autoreleaseRV returning the callee result, which makes it impossible to pair it up with the retainRV/claimRV call in the caller. If that fails, it simply emits a retain call in the IR if the implicit call is a call to retainRV and does nothing if it's a call to claimRV.
Future work:
- Use the operand bundle on x86-64.
- Fix the auto upgrader to convert call+retainRV/claimRV pairs into calls annotated with the operand bundles.
rdar://71443534
Differential Revision: https://reviews.llvm.org/D92808
show more ...
|
#
50c523a9 |
| 02-Feb-2021 |
Jeroen Dobbelaere <jeroen.dobbelaere@synopsys.com> |
[InlineFunction] Only update noalias scopes once for an instruction.
Inlining sometimes maps different instructions to be inlined onto the same instruction.
We must ensure to only remap the noalias
[InlineFunction] Only update noalias scopes once for an instruction.
Inlining sometimes maps different instructions to be inlined onto the same instruction.
We must ensure to only remap the noalias scopes once. Otherwise the scope might disappear (at best). This patch ensures that we only replace scopes for which the mapping is known.
This approach is preferred over tracking which instructions we already handled in a SmallPtrSet, as that one will need more memory.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D95862
show more ...
|
#
925ae8c7 |
| 25-Jan-2021 |
Richard Smith <richard@metafoo.co.uk> |
Revert "[ObjC][ARC] Annotate calls with attributes instead of emitting retainRV"
This reverts commit 53176c168061d6f26dcf3ce4fa59288b7d67255e, which introduceed a layering violation. LLVM's IR libra
Revert "[ObjC][ARC] Annotate calls with attributes instead of emitting retainRV"
This reverts commit 53176c168061d6f26dcf3ce4fa59288b7d67255e, which introduceed a layering violation. LLVM's IR library can't include headers from Analysis.
show more ...
|
#
53176c16 |
| 25-Jan-2021 |
Akira Hatanaka <ahatanaka@apple.com> |
[ObjC][ARC] Annotate calls with attributes instead of emitting retainRV or claimRV calls in the IR
Background:
This patch makes changes to the front-end and middle-end that are needed to fix a long
[ObjC][ARC] Annotate calls with attributes instead of emitting retainRV or claimRV calls in the IR
Background:
This patch makes changes to the front-end and middle-end that are needed to fix a longstanding problem where llvm breaks ARC's autorelease optimization (see the link below) by separating calls from the marker instructions or retainRV/claimRV calls. The backend changes are in https://reviews.llvm.org/D92569.
https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-autoreleasereturnvalue
What this patch does to fix the problem:
- The front-end annotates calls with attribute "clang.arc.rv"="retain" or "clang.arc.rv"="claim", which indicates the call is implicitly followed by a marker instruction and a retainRV/claimRV call that consumes the call result. This is currently done only when the target is arm64 and the optimization level is higher than -O0.
- ARC optimizer temporarily emits retainRV/claimRV calls after the annotated calls in the IR and removes the inserted calls after processing the function.
- ARC contract pass emits retainRV/claimRV calls after the annotated calls. It doesn't remove the attribute on the call since the backend needs it to emit the marker instruction. The retainRV/claimRV calls are emitted late in the pipeline to prevent optimization passes from transforming the IR in a way that makes it harder for the ARC middle-end passes to figure out the def-use relationship between the call and the retainRV/claimRV calls (which is the cause of PR31925).
- The function inliner removes the autoreleaseRV call in the callee that returns the result if nothing in the callee prevents it from being paired up with the calls annotated with "clang.arc.rv"="retain/claim" in the caller. If the call is annotated with "claim", a release call is inserted since autoreleaseRV+claimRV is equivalent to a release. If it cannot find an autoreleaseRV call, it tries to transfer the attributes to a function call in the callee. This is important since ARC optimizer can remove the autoreleaseRV call returning the callee result, which makes it impossible to pair it up with the retainRV or claimRV call in the caller. If that fails, it simply emits a retain call in the IR if the call is annotated with "retain" and does nothing if it's annotated with "claim".
- This patch teaches dead argument elimination pass not to change the return type of a function if any of the calls to the function are annotated with attribute "clang.arc.rv". This is necessary since the pass can incorrectly determine nothing in the IR uses the function return, which can happen since the front-end no longer explicitly emits retainRV/claimRV calls in the IR, and change its return type to 'void'.
Future work:
- Use the attribute on x86-64.
- Fix the auto upgrader to convert call+retainRV/claimRV pairs into calls annotated with the attributes.
rdar://71443534
Differential Revision: https://reviews.llvm.org/D92808
show more ...
|
#
8b9df70b |
| 24-Jan-2021 |
Nikita Popov <nikita.ppv@gmail.com> |
[Utils] Use NoAliasScopeDeclInst in a few more places (NFC)
In the cloning infrastructure, only track an MDNode mapping, without explicitly storing the Metadata mapping, same as is done during inlin
[Utils] Use NoAliasScopeDeclInst in a few more places (NFC)
In the cloning infrastructure, only track an MDNode mapping, without explicitly storing the Metadata mapping, same as is done during inlining. This makes things slightly simpler.
show more ...
|
#
c83cff45 |
| 23-Jan-2021 |
Nikita Popov <nikita.ppv@gmail.com> |
[IR] Add NoAliasScopeDeclInst (NFC)
Add an intrinsic type class to represent the llvm.experimental.noalias.scope.decl intrinsic, to make code working with it a bit nicer by hiding the metadata extra
[IR] Add NoAliasScopeDeclInst (NFC)
Add an intrinsic type class to represent the llvm.experimental.noalias.scope.decl intrinsic, to make code working with it a bit nicer by hiding the metadata extraction from view.
show more ...
|
#
2b9a834c |
| 23-Jan-2021 |
Jeroen Dobbelaere <jeroen.dobbelaere@synopsys.com> |
[InlineFunction] Use llvm.experimental.noalias.scope.decl for noalias arguments.
Insert a llvm.experimental.noalias.scope.decl intrinsic that identifies where a noalias argument was inlined.
This p
[InlineFunction] Use llvm.experimental.noalias.scope.decl for noalias arguments.
Insert a llvm.experimental.noalias.scope.decl intrinsic that identifies where a noalias argument was inlined.
This patch includes some refactorings from D90104.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D93040
show more ...
|
#
8a20e2b3 |
| 13-Jan-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Use Optional::getValueOr (NFC)
|
#
76f6b125 |
| 07-Jan-2021 |
Oliver Stannard <oliver.stannard@linaro.org> |
Revert "[llvm] Use BasicBlock::phis() (NFC)"
Reverting because this causes crashes on the 2-stage buildbots, for example http://lab.llvm.org:8011/#/builders/7/builds/1140.
This reverts commit 9b228
Revert "[llvm] Use BasicBlock::phis() (NFC)"
Reverting because this causes crashes on the 2-stage buildbots, for example http://lab.llvm.org:8011/#/builders/7/builds/1140.
This reverts commit 9b228f107d43341ef73af92865f73a9a076c5a76.
show more ...
|
#
9b228f10 |
| 07-Jan-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Use BasicBlock::phis() (NFC)
|
#
530c5af6 |
| 02-Jan-2021 |
Kazu Hirata <kazu@google.com> |
[Transforms] Construct SmallVector with iterator ranges (NFC)
|
#
8299fb8f |
| 27-Dec-2020 |
Kazu Hirata <kazu@google.com> |
[Transforms] Use llvm::append_range (NFC)
|
#
b6211167 |
| 18-Dec-2020 |
Kazu Hirata <kazu@google.com> |
[Transforms] Use llvm::erase_if (NFC)
|
#
b5ad32ef |
| 11-Dec-2020 |
Fangrui Song <i@maskray.me> |
Migrate deprecated DebugLoc::get to DILocation::get
This migrates all LLVM (except Kaleidoscope and CodeGen/StackProtector.cpp) DebugLoc::get to DILocation::get.
The CodeGen/StackProtector.cpp usag
Migrate deprecated DebugLoc::get to DILocation::get
This migrates all LLVM (except Kaleidoscope and CodeGen/StackProtector.cpp) DebugLoc::get to DILocation::get.
The CodeGen/StackProtector.cpp usage may have a nullptr Scope and can trigger an assertion failure, so I don't migrate it.
Reviewed By: #debug-info, dblaikie
Differential Revision: https://reviews.llvm.org/D93087
show more ...
|
#
f4a3969b |
| 18-Nov-2020 |
Nikita Popov <nikita.ppv@gmail.com> |
[Inline] Fix incorrectly dropped noalias metadata
This is the same fix as 23aeadb89df38406dc4d929d08286f7ce31040eb, just for CloneScopedAliasMetadata rather than PropagateCallSiteMetadata.
In this
[Inline] Fix incorrectly dropped noalias metadata
This is the same fix as 23aeadb89df38406dc4d929d08286f7ce31040eb, just for CloneScopedAliasMetadata rather than PropagateCallSiteMetadata.
In this case the previous outcome was incorrectly dropped metadata, as it was not part of the computed metadata map.
The real change in the test is that the first load now retains metadata, the rest of the changes are due to changes in metadata numbering.
show more ...
|
#
23aeadb8 |
| 18-Nov-2020 |
Nikita Popov <nikita.ppv@gmail.com> |
[Inline] Fix incorrect noalias metadata application (PR48209)
The VMap also contains a mapping from Argument => Instruction, where the instruction is part of the original function, not the inlined o
[Inline] Fix incorrect noalias metadata application (PR48209)
The VMap also contains a mapping from Argument => Instruction, where the instruction is part of the original function, not the inlined one. The code was assuming that all the instructions in the VMap were inlined.
This was a pre-existing problem for the loop access metadata, but was extended to the more common noalias metadata by 27f647d117087ca11959e232e6443f4aee31e966, thus causing miscompiles.
There is a similar assumption inside CloneAliasScopeMetadata(), so that one likely needs to be fixed as well.
show more ...
|
#
f4c6080a |
| 18-Nov-2020 |
Nick Desaulniers <ndesaulniers@google.com> |
Revert "[IR] add fn attr for no_stack_protector; prevent inlining on mismatch"
This reverts commit b7926ce6d7a83cdf70c68d82bc3389c04009b841.
Going with a simpler approach.
|
#
1da60f1d |
| 17-Nov-2020 |
Kazu Hirata <kazu@google.com> |
[Transforms] Use pred_empty (NFC)
|
#
27f647d1 |
| 31-Oct-2020 |
Nikita Popov <nikita.ppv@gmail.com> |
[Inliner] Consistently apply callsite noalias metadata
Previously, !noalias and !alias.scope metadata on the call site was applied as part of CloneAliasScopeMetadata(), which short-circuits if the c
[Inliner] Consistently apply callsite noalias metadata
Previously, !noalias and !alias.scope metadata on the call site was applied as part of CloneAliasScopeMetadata(), which short-circuits if the callee does not use any noalias metadata itself. However, these two things have no relation to each other.
Consistently apply !noalias and !alias.scope metadata by integrating this into an existing function that handled !llvm.access.group and !llvm.mem.parallel_loop_access metadata. The handling for all of these metadata kinds essentially the same.
show more ...
|
#
b7926ce6 |
| 23-Oct-2020 |
Nick Desaulniers <ndesaulniers@google.com> |
[IR] add fn attr for no_stack_protector; prevent inlining on mismatch
It's currently ambiguous in IR whether the source language explicitly did not want a stack a stack protector (in C, via function
[IR] add fn attr for no_stack_protector; prevent inlining on mismatch
It's currently ambiguous in IR whether the source language explicitly did not want a stack a stack protector (in C, via function attribute no_stack_protector) or doesn't care for any given function.
It's common for code that manipulates the stack via inline assembly or that has to set up its own stack canary (such as the Linux kernel) would like to avoid stack protectors in certain functions. In this case, we've been bitten by numerous bugs where a callee with a stack protector is inlined into an __attribute__((__no_stack_protector__)) caller, which generally breaks the caller's assumptions about not having a stack protector. LTO exacerbates the issue.
While developers can avoid this by putting all no_stack_protector functions in one translation unit together and compiling those with -fno-stack-protector, it's generally not very ergonomic or as ergonomic as a function attribute, and still doesn't work for LTO. See also: https://lore.kernel.org/linux-pm/20200915172658.1432732-1-rkir@google.com/ https://lore.kernel.org/lkml/20200918201436.2932360-30-samitolvanen@google.com/T/#u
Typically, when inlining a callee into a caller, the caller will be upgraded in its level of stack protection (see adjustCallerSSPLevel()). By adding an explicit attribute in the IR when the function attribute is used in the source language, we can now identify such cases and prevent inlining. Block inlining when the callee and caller differ in the case that one contains `nossp` when the other has `ssp`, `sspstrong`, or `sspreq`.
Fixes pr/47479.
Reviewed By: void
Differential Revision: https://reviews.llvm.org/D87956
show more ...
|
#
1e1770a0 |
| 03-Sep-2020 |
David Sherwood <david.sherwood@arm.com> |
[SVE][CodeGen] Fix InlineFunction for scalable vectors
When inlining functions containing allocas of scalable vectors we cannot specify the size in the lifetime markers, since we don't know this at
[SVE][CodeGen] Fix InlineFunction for scalable vectors
When inlining functions containing allocas of scalable vectors we cannot specify the size in the lifetime markers, since we don't know this at compile time.
Added new test here:
test/Transforms/Inline/AArch64/sve-alloca-merge.ll
Differential Revision: https://reviews.llvm.org/D87139
show more ...
|
#
b0eb40ca |
| 31-Jul-2020 |
Vitaly Buka <vitalybuka@google.com> |
[NFC] Remove unused GetUnderlyingObject paramenter
Depends on D84617.
Differential Revision: https://reviews.llvm.org/D84621
|
#
89051eba |
| 31-Jul-2020 |
Vitaly Buka <vitalybuka@google.com> |
[NFC] GetUnderlyingObject -> getUnderlyingObject
I am going to touch them in the next patch anyway
|
#
023883a8 |
| 29-Jun-2020 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
IR: Rename Argument::hasPassPointeeByValueAttr to prepare for byref
When the byref attribute is added, there will need to be two similar functions for the existing cases which have an associate valu
IR: Rename Argument::hasPassPointeeByValueAttr to prepare for byref
When the byref attribute is added, there will need to be two similar functions for the existing cases which have an associate value copy, and byref which does not. Most, but not all of the existing uses will use the existing version.
The associated size function added by D82679 also needs to contextually differ, and will help eliminate a few places still relying on pointee element types.
show more ...
|
#
69dca6ef |
| 06-Jul-2020 |
Roman Lebedev <lebedev.ri@gmail.com> |
[NFCI][IR] Introduce CallBase::Create() wrapper
Summary: It is reasonably common to want to clone some call with different bundles. Let's actually provide an interface to do that.
Reviewers: chandl
[NFCI][IR] Introduce CallBase::Create() wrapper
Summary: It is reasonably common to want to clone some call with different bundles. Let's actually provide an interface to do that.
Reviewers: chandlerc, jdoerfert, dblaikie, nickdesaulniers
Reviewed By: nickdesaulniers
Subscribers: llvm-commits, hiraditya
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83248
show more ...
|