Remove unnecessary includes of ManagedStatic.h

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

Remove unneeded cl::ZeroOrMore for cl::list options

[LegacyPM] Remove ThinLTO/LTO pipelines

Using the legacy PM for the optimization pipeline was deprecated in 13.0.0.
Following recent changes to remove non-core features of the legacy
PM/optimization

[LegacyPM] Remove ThinLTO/LTO pipelines

Using the legacy PM for the optimization pipeline was deprecated in 13.0.0.
Following recent changes to remove non-core features of the legacy
PM/optimization pipeline, remove the (Thin)LTO pipelines.

Reviewed By: MaskRay

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

show more ...

Revert "[NFC] Remove LinkAll*.h"

This reverts commit fe364e5dc78c58a915986d9a44cfd65f919a00c2.

Causes breakages, e.g. https://lab.llvm.org/buildbot/#/builders/188/builds/5266

[NFC] Remove LinkAll*.h

These were added to prevent functions from being removed by WPO.

But that doesn't make sense, correct WPO will not remove functions we actually use.

I noticed these because

[NFC] Remove LinkAll*.h

These were added to prevent functions from being removed by WPO.

But that doesn't make sense, correct WPO will not remove functions we actually use.

I noticed these because compiling cc1_main.cpp was pulling in random LLVM pass headers.

Reviewed By: MaskRay

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

show more ...

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

Generalize the pass registration mechanism used by Polly to any third-party tool

There's quite a lot of references to Polly in the LLVM CMake codebase. However
the registration pattern used by Polly

Generalize the pass registration mechanism used by Polly to any third-party tool

There's quite a lot of references to Polly in the LLVM CMake codebase. However
the registration pattern used by Polly could be useful to other external
projects: thanks to that mechanism it would be possible to develop LLVM
extension without touching the LLVM code base.

This patch has two effects:

1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it
with a generic mechanism

2. Provide a generic mechanism to register compiler extensions.

A compiler extension is similar to a pass plugin, with the notable difference
that the compiler extension can be configured to be built dynamically (like
plugins) or statically (like regular passes).

As a result, people willing to add extra passes to clang/opt can do it using a
separate code repo, but still have their pass be linked in clang/opt as built-in
passes.

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

show more ...

Sink all InitializePasses.h includes

This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of reco

Sink all InitializePasses.h includes

This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.

I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h

Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.

Reviewers: bkramer, asbirlea, bollu, jdoerfert

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

show more ...

[bugpoint] Add support for -Oz and properly enable -Os.

This patch adds -Oz as option and also properly enables support for -Os.
Currently, the existing check for -Os is dead, because the enclosing

[bugpoint] Add support for -Oz and properly enable -Os.

This patch adds -Oz as option and also properly enables support for -Os.
Currently, the existing check for -Os is dead, because the enclosing if
only checks of O1, O2 and O3.

There is still a difference between the -Oz pipeline compared to opt,
but I have not been able to track that down yet.

Reviewers: bogner, sebpop, efriedma

Reviewed By: efriedma

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

llvm-svn: 372079

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

IWYU for llvm-config.h in llvm, additions.

See r331124 for how I made a list of files missing the include.
I then ran this Python script:

for f in open('filelist.txt'):
f = f.strip()

IWYU for llvm-config.h in llvm, additions.

See r331124 for how I made a list of files missing the include.
I then ran this Python script:

for f in open('filelist.txt'):
f = f.strip()
fl = open(f).readlines()

found = False
for i in xrange(len(fl)):
p = '#include "llvm/'
if not fl[i].startswith(p):
continue
if fl[i][len(p):] > 'Config':
fl.insert(i, '#include "llvm/Config/llvm-config.h"\n')
found = True
break
if not found:
print 'not found', f
else:
open(f, 'w').write(''.join(fl))

and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p`
and tried to fix include ordering and whatnot.

No intended behavior change.

llvm-svn: 331184

show more ...

[AggressiveInstCombine] Add library initializer routine for AggressiveInstCombine library. Use it in bugpoint and llvm-opt-fuzzer to match regular InstCombine.

This should make aggressive instcombin

[AggressiveInstCombine] Add library initializer routine for AggressiveInstCombine library. Use it in bugpoint and llvm-opt-fuzzer to match regular InstCombine.

This should make aggressive instcombine usable with these tools.

llvm-svn: 330663

show more ...

Define InitLLVM to do common initialization all at once.

We have a few functions that virtually all command wants to run on
process startup/shutdown. This patch adds InitLLVM class to do that
all at

Define InitLLVM to do common initialization all at once.

We have a few functions that virtually all command wants to run on
process startup/shutdown. This patch adds InitLLVM class to do that
all at once, so that we don't need to copy-n-paste boilerplate code
to each llvm command's main() function.

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

llvm-svn: 330046

show more ...

Fix check-llvm on kernel 4.9+ with asan or msan

Summary:
Before https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.9.46&id=84638335900f1995495838fe1bd4870c43ec1f67

Fix check-llvm on kernel 4.9+ with asan or msan

Summary:
Before https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.9.46&id=84638335900f1995495838fe1bd4870c43ec1f67
test worked because memory allocated with mmap was not counted against RLIMIT_DATA.

Reviewers: eugenis

Subscribers: llvm-commits

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

llvm-svn: 312303

show more ...

[bugpoint] Do not initialize disassembler passes

We added the initilization of disassembler passes in r306208 with the goal to
bring bugpoint in line with 'opt'. However, 'opt' does itself not initi

[bugpoint] Do not initialize disassembler passes

We added the initilization of disassembler passes in r306208 with the goal to
bring bugpoint in line with 'opt'. However, 'opt' does itself not initialize
dissassembler passes. As our goal was consistency, we drop the initialization
of dissassembler passes again from bugpoint.

Thanks to Chandler for pointing this out!

llvm-svn: 306275

show more ...

Ensure backends available in 'opt' are also available in 'bugpoint'

This patch links LLVM back-ends into bugpoint the same way they are already
available in 'opt' and 'clang'. This resolves an incon

Ensure backends available in 'opt' are also available in 'bugpoint'

This patch links LLVM back-ends into bugpoint the same way they are already
available in 'opt' and 'clang'. This resolves an inconsistency that allowed the
use of LLVM backends in loadable modules that run in 'opt', but that would
prevent the debugging of these modules with bugpoint due to unavailable /
unresolved symbols.

For e.g. In D31859, Polly requires the NVPTX back-end.

Reviewers: hfinkel, bogner, chandlerc, grosser, Meinersbur

Subscribers: bollu, mgorny, grosser, Meinersbur

Tags: #polly

Contributed by: Singapuram Sanjay

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

llvm-svn: 306208

show more ...

Do not inline hot callsites for samplepgo in thinlto compile phase.

Summary: Because SamplePGO passes will be invoked twice in ThinLTO build: once at compile phase, the other at backend. We want to

Do not inline hot callsites for samplepgo in thinlto compile phase.

Summary: Because SamplePGO passes will be invoked twice in ThinLTO build: once at compile phase, the other at backend. We want to make sure the IR at the 2nd phase matches the hot part in profile, thus we do not want to inline hot callsites in the first phase.

Reviewers: tejohnson, eraman

Reviewed By: tejohnson

Subscribers: mehdi_amini, llvm-commits, Prazek

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

llvm-svn: 298428

show more ...

bugpoint: Return Errors instead of passing around strings

This replaces the threading of `std::string &Error` through all of
these APIs with checked Error returns instead. There are very few
places

bugpoint: Return Errors instead of passing around strings

This replaces the threading of `std::string &Error` through all of
these APIs with checked Error returns instead. There are very few
places here that actually emit any errors right now, but threading the
APIs through will allow us to replace a bunch of exit(1)'s that are
scattered through this code with proper error handling.

This is more or less NFC, but does move around where a couple of error
messages are printed out.

llvm-svn: 280720

show more ...

Revert "bugpoint: Stop threading errors through APIs that never fail"

This isn't the right thing to do - it turns out a number of the APIs
that "never fail" just exit(1) if something bad happens. We

Revert "bugpoint: Stop threading errors through APIs that never fail"

This isn't the right thing to do - it turns out a number of the APIs
that "never fail" just exit(1) if something bad happens. We can and
should thread Error through this instead.

That diff will make more sense with this reverted. Sorry for the
noise.

This reverts r280690

llvm-svn: 280691

show more ...

bugpoint: Stop threading errors through APIs that never fail

This simplifies ListReducer and most of its subclasses by removing the
std::string &Error that was threaded through all of them but almos

bugpoint: Stop threading errors through APIs that never fail

This simplifies ListReducer and most of its subclasses by removing the
std::string &Error that was threaded through all of them but almost
never used. If we end up needing error handling in more places here we
can reinstate it using llvm::Error instead of these unwieldy strings.

The 2 cases (out of 12) that actually can hit the error cases are a
little bit awkward now, but those will clean up as I refactor this API
further.

llvm-svn: 280690

show more ...

bugpoint: clang-format all of bugpoint. NFC

I'm going to clean up the APIs here a bit and touch many many lines
anyway.

llvm-svn: 280450

[PM] Port the always inliner to the new pass manager in a much more
minimal and boring form than the old pass manager's version.

This pass does the very minimal amount of work necessary to inline
fu

[PM] Port the always inliner to the new pass manager in a much more
minimal and boring form than the old pass manager's version.

This pass does the very minimal amount of work necessary to inline
functions declared as always-inline. It doesn't support a wide array of
things that the legacy pass manager did support, but is alse ... about
20 lines of code. So it has that going for it. Notably things this
doesn't support:

- Array alloca merging
- To support the above, bottom-up inlining with careful history
tracking and call graph updates
- DCE of the functions that become dead after this inlining.
- Inlining through call instructions with the always_inline attribute.
Instead, it focuses on inlining functions with that attribute.

The first I've omitted because I'm hoping to just turn it off for the
primary pass manager. If that doesn't pan out, I can add it here but it
will be reasonably expensive to do so.

The second should really be handled by running global-dce after the
inliner. I don't want to re-implement the non-trivial logic necessary to
do comdat-correct DCE of functions. This means the -O0 pipeline will
have to be at least 'always-inline,global-dce', but that seems
reasonable to me. If others are seriously worried about this I'd like to
hear about it and understand why. Again, this is all solveable by
factoring that logic into a utility and calling it here, but I'd like to
wait to do that until there is a clear reason why the existing
pass-based factoring won't work.

The final point is a serious one. I can fairly easily add support for
this, but it seems both costly and a confusing construct for the use
case of the always inliner running at -O0. This attribute can of course
still impact the normal inliner easily (although I find that
a questionable re-use of the same attribute). I've started a discussion
to sort out what semantics we want here and based on that can figure out
if it makes sense ta have this complexity at O0 or not.

One other advantage of this design is that it should be quite a bit
faster due to checking for whether the function is a viable candidate
for inlining exactly once per function instead of doing it for each call
site.

Anyways, hopefully a reasonable starting point for this pass.

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

llvm-svn: 278896

show more ...

[bugpoint] Add a -Os option

llvm-svn: 277295

Search for llvm-symbolizer binary in the same directory as argv[0], before
looking for it along $PATH. This allows installs of LLVM tools outside of
$PATH to find the symbolizer and produce pretty ba

Search for llvm-symbolizer binary in the same directory as argv[0], before
looking for it along $PATH. This allows installs of LLVM tools outside of
$PATH to find the symbolizer and produce pretty backtraces if they crash.

llvm-svn: 272232

show more ...

Remove every uses of getGlobalContext() in LLVM (but the C API)

At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
dest

Remove every uses of getGlobalContext() in LLVM (but the C API)

At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
destroy the context (like the global one), no longer now.

This is the first part of http://reviews.llvm.org/D19094

From: Mehdi Amini <[email protected]>
llvm-svn: 266379

show more ...