Revert "[CaptureTracking] Do not check domination"

This reverts commit 6b8b43e7af3074124e3c9e429e1fb08165799be4.

This causes clang test to fail (CodeGenObjC/synchronized.m).
Revert until I can figu

Revert "[CaptureTracking] Do not check domination"

This reverts commit 6b8b43e7af3074124e3c9e429e1fb08165799be4.

This causes clang test to fail (CodeGenObjC/synchronized.m).
Revert until I can figure out whether that's an expected change.

show more ...

[CaptureTracking] Do not check domination

For the CapturesBefore tracker, it is sufficient to check that
I can not reach BeforeHere. This does not necessarily require
that BeforeHere dominates I, it

[CaptureTracking] Do not check domination

For the CapturesBefore tracker, it is sufficient to check that
I can not reach BeforeHere. This does not necessarily require
that BeforeHere dominates I, it can also occur if the capture
happens on an entirely disjoint path.

This change was previously accepted in D90688, but had to be
reverted due to large compile-time impact in some cases: It
increases the number of reachability queries that are performed.

After recent changes, the compile-time impact is largely mitigated,
so I'm reapplying this patch. The remaining compile-time impact
is largely proportional to changes in code-size.

show more ...

[CaptureTracking] Only check reachability for capture candidates

Reachability queries are very expensive, and currently performed
for each instruction we look at, even though most of them will
not l

[CaptureTracking] Only check reachability for capture candidates

Reachability queries are very expensive, and currently performed
for each instruction we look at, even though most of them will
not lead to a capture and are thus ultimately irrelevant. It is
more efficient to walk a few unnecessary instructions than to
perform unnecessary reachability queries.

Theoretically, this may produce worse results, because the additional
instructions considered may cause us to hit the use count limit
earlier. In practice, this does not appear to be a problem, e.g.
on test-suite O3 we report only one more captured-before with this
change, with no resulting codegen differences.

This makes PointerMayBeCapturedBefore() significantly cheaper in
practice, hopefully allowing it to be used in more places.

show more ...

[IR] Add BasicBlock::isEntryBlock() (NFC)

This is a recurring and somewhat awkward pattern. Add a helper
method for it.

[CaptureTracking] Clean up same instruction check (NFC)

Check the BeforeHere == I case once in shouldExplore, instead of
handling it in four different places.

[CaptureTracking] Use isIdentifiedFunctionLocal() (NFC)

These conditions together exactly match isIdentifiedFunctionLocal(),
and this is also what we logically want to check for here.

Update basic deref API to account for possiblity of free [NFC]

This patch is plumbing to support work towards the goal outlined in the recent llvm-dev post "[llvm-dev] RFC: Decomposing deref(N) into

Update basic deref API to account for possiblity of free [NFC]

This patch is plumbing to support work towards the goal outlined in the recent llvm-dev post "[llvm-dev] RFC: Decomposing deref(N) into deref(N) + nofree".

The point of this change is purely to simplify iteration on other pieces on way to making the switch. Rebuilding with a change to Value.h is slow and painful, so I want to get the API change landed. Once that's done, I plan to more closely audit each caller, add the inference rules in their own patch, then post a patch with the langref changes and test diffs. The value of the command line flag is that we can exercise the inference logic in standalone patches without needing the whole switch ready to go just yet.

Differential Revision: https://reviews.llvm.org/D98908

show more ...

[CaptureTracking] Add statistics (NFC)

Add basic statistics on the number of pointers that have been
determined to maybe capture / not capture.

[CaptureTracking] Early abort on too many uses (NFCI)

If there are too many uses, we should directly return -- there's
no point in inspecting the remaining uses in the worklist, as we
have to conser

[CaptureTracking] Early abort on too many uses (NFCI)

If there are too many uses, we should directly return -- there's
no point in inspecting the remaining uses in the worklist, as we
have to conservatively assume a capture anyway. This also means
that tooManyUses() gets called exactly once, rather than
potentially many times.

This restores the behavior prior to e9832dfdf366ddffba68164adb6855d17c9f87c1,
where this was accidentally changed while moving the AddUses logic
into a closure, thus making the return a return from the closure
rather than the whole function.

show more ...

[CaptureTracking] Correctly handle multiple uses in one instruction

If the same value is used multiple times in the same instruction,
CaptureTracking may end up reporting the wrong use as being capt

[CaptureTracking] Correctly handle multiple uses in one instruction

If the same value is used multiple times in the same instruction,
CaptureTracking may end up reporting the wrong use as being captured,
and/or report the same use as being captured multiple times.

Make sure that all checks take the use operand number into account,
rather than performing unreliable comparisons against the used value.

I'm not sure whether this can cause any problems in practice, but
at least some capture trackers (ArgUsesTracker, AACaptureUseTracker)
do care about which call argument is captured.

show more ...

[CaptureTracking] Avoid duplicate shouldExplode() check (NFCI)

We check shouldExplore() before adding uses to the worklist, so
uses that should not be explored will not reach captured() in the
first

[CaptureTracking] Avoid duplicate shouldExplode() check (NFCI)

We check shouldExplore() before adding uses to the worklist, so
uses that should not be explored will not reach captured() in the
first place.

show more ...

Revert "[CaptureTracking] Avoid overly restrictive dominates check"

This reverts commit 15694fd6ad955c6a16b446a6324364111a49ae8b.
Need to investigate and fix a failing clang test: synchronized.m.
Mi

Revert "[CaptureTracking] Avoid overly restrictive dominates check"

This reverts commit 15694fd6ad955c6a16b446a6324364111a49ae8b.
Need to investigate and fix a failing clang test: synchronized.m.
Might need a test update.

show more ...

[CaptureTracking] Avoid overly restrictive dominates check

CapturesBefore tracker has an overly restrictive dominates check when
the `BeforeHere` and the capture point are in different basic blocks.

[CaptureTracking] Avoid overly restrictive dominates check

CapturesBefore tracker has an overly restrictive dominates check when
the `BeforeHere` and the capture point are in different basic blocks.
All we need to check is that there is no path from the capture point
to `BeforeHere` (which is less stricter than the dominates check).
See added testcase in one of the users of CapturesBefore.

Reviewed-By: jdoerfert
Differential Revision: https://reviews.llvm.org/D90688

show more ...

[NFC][CaptureTracking] Move static function isNonEscapingLocalObject to llvm namespace

Function isNonEscapingLocalObject is a static one within BasicAliasAnalysis.cpp.
It wraps around PointerMayBeCa

[NFC][CaptureTracking] Move static function isNonEscapingLocalObject to llvm namespace

Function isNonEscapingLocalObject is a static one within BasicAliasAnalysis.cpp.
It wraps around PointerMayBeCaptured of CaptureTracking, checking whether a pointer
is to a function-local object, which never escapes from the function.

Although at the moment, isNonEscapingLocalObject is used only by BasicAliasAnalysis,
its functionality can be used by other pass(es), one of which I will put up for review
very soon. Instead of copying the contents of this static function, I move it to llvm
scope, and place it amongst other functions with similar functionality in CaptureTracking.

The rationale for the location are:
- Pointer escape and pointer being captured are actually two sides of the same coin
- isNonEscapingLocalObject is wrapping around another function in CaptureTracking

Reviewed By: jdoerfert (Johannes Doerfert)

Differential Revision: https://reviews.llvm.org/D89465

show more ...

[NFC] GetUnderlyingObject -> getUnderlyingObject

I am going to touch them in the next patch anyway

[Analysis] Ensure we include CommandLine.h if we declare any cl::opt flags. NFC.

[CaptureTracking] Make MaxUsesToExplore cheaper (NFC)

The change in D78624 had a noticeable negative compile-time impact.
It seems that going through a function call for the MaxUsesToExplore
default

[CaptureTracking] Make MaxUsesToExplore cheaper (NFC)

The change in D78624 had a noticeable negative compile-time impact.
It seems that going through a function call for the MaxUsesToExplore
default is fairly expensive, at least if LLVM is not built with LTO.

This patch makes MaxUsesToExpore default to 0 and assigns the actual
default in the implementation instead. This recovers most of the
regression.

Differential Revision: https://reviews.llvm.org/D78734

show more ...

[CaptureTracking] Replace hardcoded constant to option. NFC.

The motivation is to be able to play with the option and change if it is required.

Reviewers: fedor.sergeev, apilipenko, rnk, jdoerfert

[CaptureTracking] Replace hardcoded constant to option. NFC.

The motivation is to be able to play with the option and change if it is required.

Reviewers: fedor.sergeev, apilipenko, rnk, jdoerfert
Reviewed By: fedor.sergeev
Subscribers: hiraditya, dantrushin, llvm-commits
Differential Revision: https://reviews.llvm.org/D78624

show more ...

[IR] Lazily number instructions for local dominance queries

Essentially, fold OrderedBasicBlock into BasicBlock, and make it
auto-invalidate the instruction ordering when new instructions are
added.

[IR] Lazily number instructions for local dominance queries

Essentially, fold OrderedBasicBlock into BasicBlock, and make it
auto-invalidate the instruction ordering when new instructions are
added. Notably, we don't need to invalidate it when removing
instructions, which is helpful when a pass mostly delete dead
instructions rather than transforming them.

The downside is that Instruction grows from 56 bytes to 64 bytes. The
resulting LLVM code is substantially simpler and automatically handles
invalidation, which makes me think that this is the right speed and size
tradeoff.

The important change is in SymbolTableTraitsImpl.h, where the numbering
is invalidated. Everything else should be straightforward.

We probably want to implement a fancier re-numbering scheme so that
local updates don't invalidate the ordering, but I plan for that to be
future work, maybe for someone else.

Reviewed By: lattner, vsk, fhahn, dexonsmith

Differential Revision: https://reviews.llvm.org/D51664

show more ...

[CaptureTracker] Let subclasses provide dereferenceability information

Summary:
CaptureTracker subclasses might have better dereferenceability
information which allows null pointer checks to be no-c

[CaptureTracker] Let subclasses provide dereferenceability information

Summary:
CaptureTracker subclasses might have better dereferenceability
information which allows null pointer checks to be no-capturing.
The first user will be D59922.

Reviewers: sanjoy, hfinkel, aykevl, sstefan1, uenoku, xbolva00

Subscribers: hiraditya, bollu, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66371

llvm-svn: 369305

show more ...

[CaptureTracking] Allow null to be in either icmp operand

Summary:
Before we required the comparison against null to be "canonical", hence
null to be operand #1. This patch allows null to be in eith

[CaptureTracking] Allow null to be in either icmp operand

Summary:
Before we required the comparison against null to be "canonical", hence
null to be operand #1. This patch allows null to be in either operand,
similar to the handling of loaded globals that follows.

Reviewers: sanjoy, hfinkel, aykevl, sstefan1, uenoku

Subscribers: hiraditya, bollu, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66321

llvm-svn: 369158

show more ...

[ValueTracking] Add MustPreserveNullness arg to functions analyzing calls. (NFC)

Some uses of getArgumentAliasingToReturnedPointer and
isIntrinsicReturningPointerAliasingArgumentWithoutCapturing req

[ValueTracking] Add MustPreserveNullness arg to functions analyzing calls. (NFC)

Some uses of getArgumentAliasingToReturnedPointer and
isIntrinsicReturningPointerAliasingArgumentWithoutCapturing require the
calls/intrinsics to preserve the nullness of the argument.

For alias analysis, the nullness property does not really come into
play.

This patch explicitly sets it to true. In D61669, the alias analysis
uses will be switched to not require preserving nullness.

Reviewers: nlopes, efriedma, hfinkel, sanjoy, aqjune, jdoerfert

Reviewed By: jdoerfert

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D64150

llvm-svn: 368993

show more ...

[CaptureTracking] Don't let comparisons against null escape inbounds pointers

Pointers that are in-bounds (either through dereferenceable_or_null or
thorough a getelementptr inbounds) cannot be capt

[CaptureTracking] Don't let comparisons against null escape inbounds pointers

Pointers that are in-bounds (either through dereferenceable_or_null or
thorough a getelementptr inbounds) cannot be captured with a comparison
against null. There is no way to construct a pointer that is still in
bounds but also NULL.

This helps safe languages that insert null checks before load/store
instructions. Without this patch, almost all pointers would be
considered captured even for simple loads. With this patch, an icmp with
null will not be seen as escaping as long as certain conditions are met.

There was a lot of discussion about this patch. See the Phabricator
thread for detals.

Differential Revision: https://reviews.llvm.org/D60047

llvm-svn: 362900

show more ...

Add an optional list of blocks to avoid when looking for a path in isPotentiallyReachable.

The leads to some ambiguous overloads, so update three callers.

Differential Revision: https://reviews.llv

Add an optional list of blocks to avoid when looking for a path in isPotentiallyReachable.

The leads to some ambiguous overloads, so update three callers.

Differential Revision: https://reviews.llvm.org/D60085

llvm-svn: 357447

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...