[LLVM] Don't peek through bitcast on pointers and gep with zero indices. NFC. (#102889)

Since we are using opaque pointers now, we don't need to peek through
bitcast on pointers and gep with zero i

[LLVM] Don't peek through bitcast on pointers and gep with zero indices. NFC. (#102889)

Since we are using opaque pointers now, we don't need to peek through
bitcast on pointers and gep with zero indices.

show more ...

GlobalOpt: Handle threadlocal.address intrinsic (#88454)

This changes `GlobalOpt` to skip/look-through `threadlocal.address`
intrinsic where apropriate.

This fixes issue #73314

[GlobalOpt] Perform store->dominated load forwarding for stored once globals

The initial land incorrectly optimized forwarding non-Constants in non-nosync/norecurse functions. Bail on non-Constants

[GlobalOpt] Perform store->dominated load forwarding for stored once globals

The initial land incorrectly optimized forwarding non-Constants in non-nosync/norecurse functions. Bail on non-Constants since norecurse should cause global -> alloca promotion anyway.

The initial land also incorrectly assumed that StoredOnceStore was the only store to the global, but it actually means that only one value other than the global initializer is stored. Add a check that there's only one store.

Compile time tracker:
https://llvm-compile-time-tracker.com/compare.php?from=c80b88ee29f34078d2149de94e27600093e6c7c0&to=ef2c2b7772424b6861a75e794f3c31b45167304a&stat=instructions

Reviewed By: nikic, asbirlea, jdoerfert

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

show more ...

[GlobalStatus] Keep Visited set in isSafeToDestroyConstant()

Constants cannot be cyclic, but they can be tree-like. Keep a
visited set to ensure we do not degenerate to exponential run-time.

This f

[GlobalStatus] Keep Visited set in isSafeToDestroyConstant()

Constants cannot be cyclic, but they can be tree-like. Keep a
visited set to ensure we do not degenerate to exponential run-time.

This fixes the problem reported in https://reviews.llvm.org/D117223#3335482,
though I haven't been able to construct a concise test case for
the issue. This requires a combination of dead constants and the
kind of constant expression tree that textual IR cannot represent
(because the textual representation, unlike the in-memory
representation, is also exponential in size).

show more ...

[GlobalStatus] Skip non-pointer dead constant users

Constant expressions with a non-pointer result type used an early
exit that bypassed the later dead constant user check, and resulted
in different

[GlobalStatus] Skip non-pointer dead constant users

Constant expressions with a non-pointer result type used an early
exit that bypassed the later dead constant user check, and resulted
in different optimization outcomes depending on whether dead users
were present or not.

This fixes the issue reported in https://reviews.llvm.org/D117223#3287039.

show more ...

[GlobalStatus] Remove unused HasNonInstructionUser member (NFC)

This hasn't been used in a long time.

[GlobalStatus] Look through non-constexpr casts

analyzeGlobal() looks through non-constexpr cast instructions when
looking for users. However, this particular place only strips the
casts again if th

[GlobalStatus] Look through non-constexpr casts

analyzeGlobal() looks through non-constexpr cast instructions when
looking for users. However, this particular place only strips the
casts again if they are constexprs. We should be looking through all
casts here.

show more ...

Reapply "[GlobalOpt][FIX] Do not embed initializers into AS!=0 globals""

This reapplies commit 7dbba3376f633cabcf4df568bc9ca95f44a35203, or, put
differently, this reverts commit d9a8d20827dcddad8317

Reapply "[GlobalOpt][FIX] Do not embed initializers into AS!=0 globals""

This reapplies commit 7dbba3376f633cabcf4df568bc9ca95f44a35203, or, put
differently, this reverts commit d9a8d20827dcddad831751bc38ff178e70f0b2f5.

The test now requires the amdgpu and nvptx backend explicitly as it
won't work without properly.

show more ...

Revert "[GlobalOpt][FIX] Do not embed initializers into AS!=0 globals"

This reverts commit 7dbba3376f633cabcf4df568bc9ca95f44a35203.

There seems to be a problem with the tests, investigating now:

Revert "[GlobalOpt][FIX] Do not embed initializers into AS!=0 globals"

This reverts commit 7dbba3376f633cabcf4df568bc9ca95f44a35203.

There seems to be a problem with the tests, investigating now:
https://lab.llvm.org/buildbot/#/builders/61/builds/14574

show more ...

[GlobalOpt][FIX] Do not embed initializers into AS!=0 globals

Not all address spaces support initializers for globals and we can
therefore not set them without checking if they are allowed. This
pat

[GlobalOpt][FIX] Do not embed initializers into AS!=0 globals

Not all address spaces support initializers for globals and we can
therefore not set them without checking if they are allowed. This
patch adds a hook into TTI to check if an AS allows non-undef
initializers. We disable it for all but address space 0 by default,
NVPTX and AMDGPU targets allow all but address space 3.

Reviewed By: tra

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

show more ...

[GlobalOpt] support ConstantExpr use of global address for OptimizeGlobalAddressOfMalloc

I'm working on extending the OptimizeGlobalAddressOfMalloc to handle some more general cases. This is to add

[GlobalOpt] support ConstantExpr use of global address for OptimizeGlobalAddressOfMalloc

I'm working on extending the OptimizeGlobalAddressOfMalloc to handle some more general cases. This is to add support of the ConstantExpr use of the global variables. The function allUsesOfLoadedValueWillTrapIfNull is now iterative with the added CE use of GV. Also, the recursive function valueIsOnlyUsedLocallyOrStoredToOneGlobal is changed to iterative using a worklist with the GEP case added.

Reviewed By: efriedma

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

show more ...

[globalopt] Teach to look through `addrspacecast`.

- so that global variables in numbered address spaces could be properly
analyzed.

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

[CallSite removal][Transform] Replace CallSite with CallBase in Utils. NFC

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

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 ...

[GlobalOpt] Fix exponential compile-time with selects.

If you have a long chain of select instructions created from something
like `int* p = &g; if (foo()) p += 4; if (foo2()) p += 4;` etc., a naive

[GlobalOpt] Fix exponential compile-time with selects.

If you have a long chain of select instructions created from something
like `int* p = &g; if (foo()) p += 4; if (foo2()) p += 4;` etc., a naive
recursive visitor will recursively visit each select twice, which is
O(2^N) in the number of select instructions. Use the visited set to cut
off recursion in this case.

(No testcase because this doesn't actually change the behavior, just the
time.)

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

llvm-svn: 323910

show more ...

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...

[Transforms/Utils] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 291983

Merge two if conditions into one. NFCI.

llvm-svn: 285008

GlobalStatus: Don't walk use-lists of ConstantData

Return early from llvm::isSafeToDestroyConstant() whenever the value
`isa<ConstantData>()`. These constants are shared across the
LLVMContext. We

GlobalStatus: Don't walk use-lists of ConstantData

Return early from llvm::isSafeToDestroyConstant() whenever the value
`isa<ConstantData>()`. These constants are shared across the
LLVMContext. We never really want to delete them here, and walking
their use-lists can be very expensive.

(This is motivated by an eventual goal of removing use-lists entirely
from ConstantData.)

llvm-svn: 282320

show more ...

IR: Introduce local_unnamed_addr attribute.

If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing un

IR: Introduce local_unnamed_addr attribute.

If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing unnamed_addr attribute in that it only describes a local property
of the module rather than a global property of the symbol.

This attribute is intended to be used by the code generator and LTO to allow
the linker to decide whether the global needs to be in the symbol table. It is
possible to exclude a global from the symbol table if three things are true:
- This attribute is present on every instance of the global (which means that
the normal rule that the global must have a unique address can be broken without
being observable by the program by performing comparisons against the global's
address)
- The global has linkonce_odr linkage (which means that each linkage unit must have
its own copy of the global if it requires one, and the copy in each linkage unit
must be the same)
- It is a constant or a function (which means that the program cannot observe that
the unique-address rule has been broken by writing to the global)

Although this attribute could in principle be computed from the module
contents, LTO clients (i.e. linkers) will normally need to be able to compute
this property as part of symbol resolution, and it would be inefficient to
materialize every module just to compute it.

See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
for earlier discussion.

Part of the fix for PR27553.

Differential Revision: http://reviews.llvm.org/D20348

llvm-svn: 272709

show more ...

NFC: make AtomicOrdering an enum class

Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 b

NFC: make AtomicOrdering an enum class

Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 barring a small question that's still open.

The code currently plays fast and loose with the AtomicOrdering
enum. Using an enum class is one step towards tightening things. I later
also want to tighten related enums, such as clang's
AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI'
enum).

This change touches a few lines of code which can be improved later, I'd
like to keep it as NFC for now as it's already quite complex. I have
related changes for clang.

As a follow-up I'll add:
bool operator<(AtomicOrdering, AtomicOrdering) = delete;
bool operator>(AtomicOrdering, AtomicOrdering) = delete;
bool operator<=(AtomicOrdering, AtomicOrdering) = delete;
bool operator>=(AtomicOrdering, AtomicOrdering) = delete;
This is separate so that clang and LLVM changes don't need to be in sync.

Reviewers: jyknight, reames

Subscribers: jyknight, llvm-commits

Differential Revision: http://reviews.llvm.org/D18775

llvm-svn: 265602

show more ...

GlobalOpt does not treat externally_initialized globals correctly

GlobalOpt currently merges stores into the initialisers of internal,
externally_initialized globals, but should not do so as the val

GlobalOpt does not treat externally_initialized globals correctly

GlobalOpt currently merges stores into the initialisers of internal,
externally_initialized globals, but should not do so as the value of the global
may change between the initialiser and any code in the module being run.

llvm-svn: 250035

show more ...

[CallSite] Make construction from Value* (or Instruction*) explicit.

CallSite roughly behaves as a common base CallInst and InvokeInst. Bring
the behavior closer to that model by making upcasts expl

[CallSite] Make construction from Value* (or Instruction*) explicit.

CallSite roughly behaves as a common base CallInst and InvokeInst. Bring
the behavior closer to that model by making upcasts explicit. Downcasts
remain implicit and work as before.

Following dyn_cast as a mental model checking whether a Value *V isa
CallSite now looks like this:
if (auto CS = CallSite(V)) // think dyn_cast
instead of:
if (CallSite CS = V)

This is an extra token but I think it is slightly clearer. Making the
ctor explicit has the advantage of not accidentally creating nullptr
CallSites, e.g. when you pass a Value * to a function taking a CallSite
argument.

llvm-svn: 234601

show more ...

Update SetVector to rely on the underlying set's insert to return a pair<iterator, bool>

This is to be consistent with StringSet and ultimately with the standard
library's associative container inse

Update SetVector to rely on the underlying set's insert to return a pair<iterator, bool>

This is to be consistent with StringSet and ultimately with the standard
library's associative container insert function.

This lead to updating SmallSet::insert to return pair<iterator, bool>,
and then to update SmallPtrSet::insert to return pair<iterator, bool>,
and then to update all the existing users of those functions...

llvm-svn: 222334

show more ...

Remove dangling initializers in GlobalDCE

GlobalDCE deletes global vars and updates their initializers to nullptr
while leaving underlying constants to be cleaned up later by its uses.
The clean up

Remove dangling initializers in GlobalDCE

GlobalDCE deletes global vars and updates their initializers to nullptr
while leaving underlying constants to be cleaned up later by its uses.
The clean up may never happen, fix this by forcing it every time it's
safe to destroy constants.

Final patch by Rafael Espindola
http://reviews.llvm.org/D4931

<rdar://problem/17523868>

llvm-svn: 216390

show more ...