Commit Graph

20 Commits

Author SHA1 Message Date
Chandler Carruth 2946cd7010 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
2019-01-19 08:50:56 +00:00
Eugene Zelenko 92334e07ca [Pass] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 312679
2017-09-06 23:05:38 +00:00
Francis Visoiu Mistrih 8b61764cbb [LegacyPassManager] Remove TargetMachine constructors
This provides a new way to access the TargetMachine through
TargetPassConfig, as a dependency.

The patterns replaced here are:

* Passes handling a null TargetMachine call
  `getAnalysisIfAvailable<TargetPassConfig>`.

* Passes not handling a null TargetMachine
  `addRequired<TargetPassConfig>` and call
  `getAnalysis<TargetPassConfig>`.

* MachineFunctionPasses now use MF.getTarget().

* Remove all the TargetMachine constructors.
* Remove INITIALIZE_TM_PASS.

This fixes a crash when running `llc -start-before prologepilog`.

PEI needs StackProtector, which gets constructed without a TargetMachine
by the pass manager. The StackProtector pass doesn't handle the case
where there is no TargetMachine, so it segfaults.

Related to PR30324.

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

llvm-svn: 303360
2017-05-18 17:21:13 +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
Mehdi Amini b550cb1750 [NFC] Header cleanup
Removed some unused headers, replaced some headers with forward class declarations.

Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'

Patch by Eugene Kosov <claprix@yandex.ru>

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595
2016-04-18 09:17:29 +00:00
Erik Eckstein 8c76e669c5 Revert r231276 (including r231277): Add a lock() function in PassRegistry to speed up multi-thread synchronization.
llvm-svn: 231385
2015-03-05 17:53:00 +00:00
Erik Eckstein 8c38b8b873 Add a lock() function in PassRegistry to speed up multi-thread synchronization.
When calling lock() after all passes are registered, the PassRegistry doesn't need a mutex anymore to look up passes.
This speeds up multithreaded llvm execution by ~5% (tested with 4 threads).
In an asserts build of llvm this has an even bigger impact.

Note that it's not required to use the lock function.

llvm-svn: 231276
2015-03-04 18:57:11 +00:00
Chandler Carruth 6d2472daca [PM] Remove an unused and rather expensive mapping from an analysis
group's interface to all of the implementations of that analysis group.
The groups themselves can and do manage this anyways, the pass registry
needn't involve itself.

llvm-svn: 219097
2014-10-06 00:30:59 +00:00
Chandler Carruth 9cf0b8f0eb [PM] Remove the (deeply misguided) 'unregister' functionality from the
pass registry.

This style of registry is somewhat questionable, but it being
non-monotonic is crazy. No one is (or should be) unloading DSOs with
passes and unregistering them here. I've checked with a few folks and
I don't know of anyone using this functionality or any important use
case where it is necessary.

llvm-svn: 219096
2014-10-06 00:13:25 +00:00
Chandler Carruth 484bc69aec [cleanup] Switch to using range-based for loops in two very obvious
places.

llvm-svn: 219095
2014-10-06 00:06:48 +00:00
Chandler Carruth c34cfb9c0a [cleanup] Fix up trailing whitespace and formatting in the pass regitsry
code prior to hacking on it more significantly.

llvm-svn: 219094
2014-10-05 23:59:03 +00:00
Zachary Turner 0921f6bdb8 Remove pimpl class from PassRegistry.
Since removeRegistrationListener is no longer called during static
destruction, we can get rid of the pimpl in PassRegistry.

This should clean up the code somewhat, increase clarity, and also
allows us to put the Lock as a member of the class, instead of as a
ManagedStatic.

As part of this change, the PassInfo class is moved from
PassSupport.h to its own file, to eliminate the otherwise circular
header dependency between PassRegistry.h and PassSupport.h

Reviewed by: rnk, dblaikie

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

llvm-svn: 210793
2014-06-12 16:06:51 +00:00
Zachary Turner a997d928fc Don't acquire the mutex during the destructor of PassRegistry.
This destructor is run as part of static program termination, and
so all ManagedStatics (including this lock) will have been
destroyed by llvm_shutdown.  Furthermore, if there is actually
a race condition during static program termination, then we are
just hiding a bug somewhere else, because other threads should
not be running at this point.

llvm-svn: 210717
2014-06-11 23:03:31 +00:00
David Blaikie 0afad5e8bc Use unique_ptr to manage PassInfo instances in the PassRegistry
llvm-svn: 206297
2014-04-15 15:17:14 +00:00
Craig Topper 2617dccea2 [C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr.
llvm-svn: 206252
2014-04-15 06:32:26 +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
Quentin Colombet dc0b2ea2bc [opt][PassInfo] Allow opt to run passes that need target machine.
When registering a pass, a pass can now specify a second construct that takes as
argument a pointer to TargetMachine.
The PassInfo class has been updated to reflect that possibility.
If such a constructor exists opt will use it instead of the default constructor
when instantiating the pass.

Since such IR passes are supposed to be rare, no specific support has been
added to this commit to allow an easy registration of such a pass.
In other words, for such pass, the initialization function has to be
hand-written (see CodeGenPrepare for instance).

Now, codegenprepare can be tested using opt:
opt -codegenprepare -mtriple=mytriple input.ll

llvm-svn: 199430
2014-01-16 21:44:34 +00:00
Chad Rosier 673a7db236 Use an RWMutex instead of a Mutex in PassRegistry.
Patch by Alex Crichton <alex@crichton.co>.  Approved by Chris Lattner.

llvm-svn: 185566
2013-07-03 18:38:08 +00:00
Chandler Carruth 9fb823bbd4 Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366
2013-01-02 11:36:10 +00:00
Chandler Carruth ef860a2488 Rename VMCore directory to IR.
Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

llvm-svn: 171359
2013-01-02 09:10:48 +00:00