History log of /llvm-project/llvm/lib/Transforms/Utils/InlineFunction.cpp (Results 151 – 175 of 636)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


12345678910>>...26