Commit Graph

56 Commits

Author SHA1 Message Date
Florian Hahn 03c3a1adec [PM] Use range-based for loops in LegacyPassManager.cpp (NFC).
Summary:
This patch replaces a bunch of iterator-based for loops with range-based
for loops. There are 2 iterator-based loops left in this file in
removeNotPreservedAnalysis, but I think those cannot be replaced by
range-based for loops as they modify the container they are iterating
over.

Unless I missed something, this schould be a NFC and I would appreciate
if someone could have a quick look to confirm that.

Reviewers: chandlerc, pcc, jhenderson

Reviewed By: jhenderson

Subscribers: llvm-commits, mehdi_amini

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

llvm-svn: 307902
2017-07-13 10:52:00 +00:00
Mandeep Singh Grang 5e1697ef28 [llvm] Remove double semicolons
Reviewers: craig.topper, arsenm, mehdi_amini

Reviewed By: mehdi_amini

Subscribers: mehdi_amini, wdng, nhaehnle, javed.absar, llvm-commits

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

llvm-svn: 304767
2017-06-06 05:08:36 +00:00
James Henderson 852f6fde01 [LTO] Print time-passes information at conclusion of LTO codegen
The information collected when requested by -time-passes is only printed when
llvm_shutdown is called at the moment. This means that when linking against the LTO
library dynamically and using the C interface, it is not possible to see the timing
information, because llvm_shutdown cannot be called. This change modifies the LTO
code generation functions for both regular LTO and thin LTO to explicitly print and
reset the timing information.

I have tested that this works with our proprietary linker. However, as this relies
on a specific method of building and linking against the LTO library, I'm not sure
how or if this can be tested in the LLVM testsuite.

Reviewed by: mehdi_amini

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

llvm-svn: 303152
2017-05-16 09:43:21 +00:00
Serge Pavlov ed5eb93384 Reverted: Track validity of pass results
Commits r291882 and related r291887.

llvm-svn: 292062
2017-01-15 10:23:18 +00:00
Serge Pavlov d409411ef1 Track validity of pass results
Running tests with expensive checks enabled exhibits some problems with
verification of pass results.

First, the pass verification may require results of analysis that are not
available. For instance, verification of loop info requires results of dominator
tree analysis. A pass may be marked as conserving loop info but does not need to
be dependent on DominatorTreePass. When a pass manager tries to verify that loop
info is valid, it needs dominator tree, but corresponding analysis may be
already destroyed as no user of it remained.

Another case is a pass that is skipped. For instance, entities with linkage
available_externally do not need code generation and such passes are skipped for
them. In this case result verification must also be skipped.

To solve these problems this change introduces a special flag to the Pass
structure to mark passes that have valid results. If this flag is reset,
verifications dependent on the pass result are skipped.

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

llvm-svn: 291882
2017-01-13 06:09:54 +00:00
Matthias Braun 9f15a79e5d Timer: Track name and description.
The previously used "names" are rather descriptions (they use multiple
words and contain spaces), use short programming language identifier
like strings for the "names" which should be used when exporting to
machine parseable formats.

Also removed a unused TimerGroup from Hexxagon.

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

llvm-svn: 287369
2016-11-18 19:43:18 +00:00
Peter Collingbourne 7f00d0a125 Bitcode: Change the materializer interface to return llvm::Error.
Differential Revision: https://reviews.llvm.org/D26439

llvm-svn: 286382
2016-11-09 17:49:19 +00:00
Pavel Labath ec534e6dfe Replace TimeValue by TimePoint in LegacyPassManager. NFC.
llvm-svn: 285081
2016-10-25 16:20:07 +00:00
Mehdi Amini 732afdd09a Turn cl::values() (for enum) from a vararg function to using C++ variadic template
The core of the change is supposed to be NFC, however it also fixes
what I believe was an undefined behavior when calling:

 va_start(ValueArgs, Desc);

with Desc being a StringRef.

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

llvm-svn: 283671
2016-10-08 19:41:06 +00:00
Yaron Keren bd8731946c Rangify for loops.
llvm-svn: 283074
2016-10-02 19:21:41 +00:00
Mehdi Amini 117296c0a0 Use StringRef in Pass/PassManager APIs (NFC)
llvm-svn: 283004
2016-10-01 02:56:57 +00:00
David Majnemer 0d955d0bf5 Use the range variant of find instead of unpacking begin/end
If the result of the find is only used to compare against end(), just
use is_contained instead.

No functionality change is intended.

llvm-svn: 278433
2016-08-11 22:21:41 +00:00
Yaron Keren 3189622ae5 Remove doInitialization() and doFinalization() member declarations without definitions.
Visual C++ 2015 flags this in the IDE.

llvm-svn: 267919
2016-04-28 19:21:30 +00:00
Yaron Keren 8300995548 Rangify for loops, NFC.
llvm-svn: 267889
2016-04-28 14:49:44 +00:00
Yaron Keren eb2a25467e Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith r259192 post commit comment.
clang part in r259232, this is the LLVM part of the patch.

llvm-svn: 259240
2016-01-29 20:50:44 +00:00
Weiming Zhao 0f1762caf9 Recommit r256952 "Filtering IR printing for print-after-all/print-before-all"
Fix lit test fail due to outputting an extra line.

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

llvm-svn: 256987
2016-01-06 22:55:03 +00:00
Weiming Zhao b243c95c6a Revert r256952 due to lit test fails.
llvm-svn: 256954
2016-01-06 18:31:44 +00:00
Weiming Zhao eac0636805 Filtering IR printing for print-after-all/print-before-all
Summary:
This patch implements "-print-funcs" option to support function filtering for IR printing like -print-after-all, -print-before etc.
Examples:
  -print-after-all -print-funcs=foo,bar

Reviewers: mcrosier, joker.eph

Subscribers: tejohnson, joker.eph, llvm-commits

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

llvm-svn: 256952
2016-01-06 18:20:25 +00:00
Philip Reames e53cb2fd9b Remove debug output that snuck into 254957
llvm-svn: 254960
2015-12-07 22:43:56 +00:00
Philip Reames 9e5e2d61bf Reapply 254950 w/fix
254950 ended up being not NFC.  The previous code was overriding the flags for whether an instruction read or wrote memory using the target specific flags returned via TTI.  I'd missed this in my refactoring.  Since I mistakenly built only x86 and didn't notice the number of unsupported tests, I didn't catch that before the original checkin.

This raises an interesting issue though.  Given we have function attributes (i.e. readonly, readnone, argmemonly) which describe the aliasing of intrinsics, why does TTI have this information overriding the instruction definition at all?  I see no reason for this, but decided to preserve existing behavior for the moment.  The root issue might be that we don't have a "writeonly" attribute.

Original commit message:
[EarlyCSE] Simplify and invert ParseMemoryInst [NFCI]

Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable.

The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile.

Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful.

llvm-svn: 254957
2015-12-07 22:41:23 +00:00
Philip Reames 000f77d728 [PassManager] Ensure destructors of cached AnalysisUsage objects are run
In 254760, I introduced the usage of a BumpPtrAllocator for the AnalysisUsage instances held by the PassManger.  This turns out to have been incorrect since a BumpPtrAllocator does not run the destructors of objects when deallocating memory.  Since a few of our SmallVector's had grown beyond their small size, we end up with some leaked memory.  We need to use a SpecificBumpPtrAllocator instead.

llvm-svn: 254803
2015-12-04 23:48:19 +00:00
Philip Reames e8aeaeb712 [LegacyPassManager] Reduce memory usage for AnalysisUsage
The LegacyPassManager was storing an instance of AnalysisUsage for each instance of each pass. In practice, most instances of a single pass class share the same dependencies. We can't rely on this because passes can (and some do) have dynamic dependencies based on instance options.

We can exploit the likely commonality by uniqueing the usage information after querying the pass, but before storing it into the pass manager. This greatly reduces memory consumption by the AnalysisUsage objects. For a long pass pipeline, I measured a decrease in memory consumption for this storage of about 50%. I have not measured on the default O3 pipeline, but I suspect it will see some benefit as well since many passes are repeated (e.g. InstCombine).

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

llvm-svn: 254760
2015-12-04 20:05:04 +00:00
Jakub Staszak 225d3ab801 Simplify code. No functionality change.
llvm-svn: 249335
2015-10-05 18:53:30 +00:00
Chandler Carruth 87275186d1 [LPM] Simplify this code and fix a compile error for compilers that
don't correctly implement the scoping rules of C++11 range based for
loops. This kind of aliasing isn't a good idea anyways (and wasn't
really intended).

llvm-svn: 247241
2015-09-10 04:22:36 +00:00
Chandler Carruth b1e3a9ae8d [LPM] Use a map from analysis ID to immutable passes in the legacy pass
manager to avoid a slow linear scan of every immutable pass and on every
attempt to find an analysis pass.

This speeds up 'check-llvm' on an unoptimized build for me by 15%, YMMV.
It should also help (a tiny bit) other folks that are really
bottlenecked on repeated runs of tiny pass pipelines across small IR
files.

llvm-svn: 247240
2015-09-10 02:31:42 +00:00
Chandler Carruth 44a1385c45 [LPM] Teach the legacy pass manager to support *using* an analysis
without *requiring* it.

This allows a pass indicate that it will use an analysis if available
(through getAnalysisIfAvailable). When the pass manager knows this, it
will refrain from deleting that analysis if it can. Naturally, it will
still get invalidated at the correct time. These passes are not
considered when scheduling the pass pipeline, so typically they will
require manual scheduling, but this may also allow passes with
getAnalysisIfAvailable to find the analysis more often if nothing after
them requires that analysis and it wasn't invalidated.

I don't have a particular use case with the current passes, but with my
new structure for alias analyses, this will be very useful. We want to
allow people to customize the set of AAs available by scheduling
additional passes. These's aren't ever *required* for obvious reasons.
So we need some way to mark in the legacy pass manager that they will
still be used if available.

This is essentially how analysis groups already work. But this makes the
feature generally available and more explicit. It should allow the AA
change to not impact how people trigger a custom alias analysis being
available at a certain point in compilation.

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

llvm-svn: 245409
2015-08-19 03:02:12 +00:00
Chandler Carruth 2f02ea462c [LPM] Cleanup some loops to be range based for loops before hacking on
this code. NFC.

llvm-svn: 245327
2015-08-18 18:41:53 +00:00
Alexander Kornienko f00654e31b Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)
Apparently, the style needs to be agreed upon first.

llvm-svn: 240390
2015-06-23 09:49:53 +00:00
Alexander Kornienko 70bc5f1398 Fixed/added namespace ending comments using clang-tidy. NFC
The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
  -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
  llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137
2015-06-19 15:57:42 +00:00
Yaron Keren 4849aa35b7 Rangify more for loops in LegacyPassManager.cpp.
llvm-svn: 239166
2015-06-05 17:48:47 +00:00
Yaron Keren 3b1e24be56 Rangify for loops in LegacyPassManager.cpp.
llvm-svn: 239155
2015-06-05 14:15:07 +00:00
Chris Bieneman 664294cf37 [NFC] Converting to range-based for.
llvm-svn: 236163
2015-04-29 21:45:22 +00:00
Alexander Kornienko f817c1cb9a Use 'override/final' instead of 'virtual' for overridden methods
The patch is generated using clang-tidy misc-use-override check.

This command was used:

  tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
    -checks='-*,misc-use-override' -header-filter='llvm|clang' \
    -j=32 -fix -format

http://reviews.llvm.org/D8925

llvm-svn: 234679
2015-04-11 02:11:45 +00:00
Chad Rosier c83fa9e9eb Typo.
llvm-svn: 232819
2015-03-20 15:45:14 +00:00
Chandler Carruth 5b0d3e3f3a [LPM] A targeted but somewhat horrible fix to the legacy pass manager's
querying of the pass registry.

The pass manager relies on the static registry of PassInfo objects to
perform all manner of its functionality. I don't understand why it does
much of this. My very vague understanding is that this registry is
touched both during static initialization *and* while each pass is being
constructed. As a consequence it is hard to make accessing it not
require a acquiring some lock. This lock ends up in the hot path of
setting up, tearing down, and invaliditing analyses in the legacy pass
manager.

On most systems you can observe this as a non-trivial % of the time
spent in 'ninja check-llvm'. However, I haven't really seen it be more
than 1% in extreme cases of compiling more real-world software,
including LTO.

Unfortunately, some of the GPU JITs are seeing this taking essentially
all of their time because they have very small IR running through
a small pass pipeline very many times (at least, this is the vague
understanding I have of it).

This patch tries to minimize the cost of looking up PassInfo objects by
leveraging the fact that the objects themselves are immutable and they
are allocated separately on the heap and so don't have their address
change. It also requires a change I made the last time I tried to debug
this problem which removed the ability to de-register a pass from the
registry. This patch creates a single access path to these objects
inside the PMTopLevelManager which memoizes the result of querying the
registry. This is somewhat gross as I don't really know if
PMTopLevelManager is the *right* place to put it, and I dislike using
a mutable member to memoize things, but it seems to work.

For long-lived pass managers this should completely eliminate
the cost of acquiring locks to look into the pass registry once the
memoized cache is warm. For 'ninja check' I measured about 1.5%
reduction in CPU time and in total time on a machine with 32 hardware
threads. For normal compilation, I don't know how much this will help,
sadly. We will still pay the cost while we populate the memoized cache.
I don't think it will hurt though, and for LTO or compiles with many
small functions it should still be a win. However, for tight loops
around a pass manager with many passes and small modules, this will help
tremendously. On the AArch64 backend I saw nearly 50% reductions in time
to complete 2000 cycles of spinning up and tearing down the pipeline.
Measurements from Owen of an actual long-lived pass manager show more
along the lines of 10% improvements.

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

llvm-svn: 227299
2015-01-28 09:47:21 +00:00
Matthias Braun 0880c6098f Document that PassManager::add() may delete the pass right away.
Also remove redundant documentation:
- doxygen will copy documentation to overriden methods.
- Use \copydoc on PIMPL classes instead of replicating the text.

llvm-svn: 224089
2014-12-12 01:27:01 +00:00
Rafael Espindola 246c4fb5d9 Remove redundant calls to isMaterializable.
This removes calls to isMaterializable in the following cases:

* It was redundant with a call to isDeclaration now that isDeclaration returns
  the correct answer for materializable functions.
* It was followed by a call to Materialize. Just call Materialize and check EC.

llvm-svn: 221050
2014-11-01 16:46:18 +00:00
Rafael Espindola 5a52e6dc9e Modernize the error handling of the Materialize function.
llvm-svn: 220600
2014-10-24 22:50:48 +00:00
Craig Topper 4627679cec Use range based for loops to avoid needing to re-mention SmallPtrSet size.
llvm-svn: 216351
2014-08-24 23:23:06 +00:00
Sylvestre Ledru 469de19a09 Fix typos:
* libaries => libraries
* avaiable => available

llvm-svn: 215366
2014-08-11 18:04:46 +00:00
Juergen Ributzka 34390c70a5 Add C API for thread yielding callback.
Sometimes a LLVM compilation may take more time then a client would like to
wait for. The problem is that it is not possible to safely suspend the LLVM
thread from the outside. When the timing is bad it might be possible that the
LLVM thread holds a global mutex and this would block any progress in any other
thread.

This commit adds a new yield callback function that can be registered with a
context. LLVM will try to yield by calling this callback function, but there is
no guaranteed frequency. LLVM will only do so if it can guarantee that
suspending the thread won't block any forward progress in other LLVM contexts
in the same process.

Once the client receives the call back it can suspend the thread safely and
resume it at another time.

Related to <rdar://problem/16728690>

llvm-svn: 208945
2014-05-16 02:33:15 +00:00
Juergen Ributzka bcbed0a549 Revert "[PM] Add pass run listeners to the pass manager."
Revert the current implementation and C API. New implementation and C APIs are
in the works.

llvm-svn: 208904
2014-05-15 17:49:20 +00:00
Juergen Ributzka 4989255432 [PM] Add pass run listeners to the pass manager.
This commit provides the necessary C/C++ APIs and infastructure to enable fine-
grain progress report and safe suspension points after each pass in the pass
manager.

Clients can provide a callback function to the pass manager to call after each
pass. This can be used in a variety of ways (progress report, dumping of IR
between passes, safe suspension of threads, etc).

The run listener list is maintained in the LLVMContext, which allows a multi-
threaded client to be only informed for it's own thread. This of course assumes
that the client created a LLVMContext for each thread.

This fixes <rdar://problem/16728690>

llvm-svn: 207430
2014-04-28 18:19:25 +00:00
Chandler Carruth 20c5693e9e Teach the pass manager's execution dump to print the current time before
each line. This is particularly nice for tracking which run of
a particular pass over a particular function was slow.

This also required making the TimeValue string much more useful. First,
there is a standard format for writing out a date and time. Let's use
that rather than strings that would have to be parsed. Second, actually
output the nanosecond resolution that timevalue claims to have.

This is proving useful working on PR19499, so I figured it would be
generally useful to commit.

llvm-svn: 207385
2014-04-27 23:59:25 +00:00
Craig Topper c620761ca5 [C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr.
llvm-svn: 205831
2014-04-09 06:08:46 +00:00
Andrew Trick 02066f2a4d Fix a (legacy) PassManager crash that occurs when a ModulePass
indirectly requires a function analysis.

This bug was reported by Jason Kim. He included a test case here:
http://reviews.llvm.org/D3312

llvm-svn: 205753
2014-04-08 03:40:34 +00:00
Craig Topper f398d7c6bf [C++11] Add 'override' keyword to IR library.
llvm-svn: 202939
2014-03-05 06:35:38 +00:00
Chandler Carruth 1b69ed8f6a [Modules] Move the PassNameParser to the IR library as it deals in the
PassInfo structures of the legacy pass manager. Also give it the Legacy
prefix as it is not a particularly widely used header.

llvm-svn: 202839
2014-03-04 12:32:42 +00:00
Eric Christopher a13839f5ca Remove unnecessary llvm:: qualification.
llvm-svn: 202316
2014-02-26 23:27:16 +00:00
Chandler Carruth 9d805139bd [PM] Simplify the interface exposed for IR printing passes.
Nothing was using the ability of the pass to delete the raw_ostream it
printed to, and nothing was trying to pass it a pointer to the
raw_ostream. Also, the function variant had a different order of
arguments from all of the others which was just really confusing. Now
the interface accepts a reference, doesn't offer to delete it, and uses
a consistent order. The implementation of the printing passes haven't
been updated with this simplification, this is just the API switch.

llvm-svn: 199044
2014-01-12 11:30:46 +00:00