summaryrefslogtreecommitdiffstats
path: root/llvm/examples/ParallelJIT
Commit message (Collapse)AuthorAgeFilesLines
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-1/+1
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* Fix compilation of examples after 13680223b9d8 / r352827James Y Knight2019-02-011-10/+12
| | | | | | Who knew...they're not built by default or as part of the tests. llvm-svn: 352830
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-7/+8
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
* Defeat another -Wunused-but-set-variable warningHans Wennborg2017-07-191-0/+1
| | | | llvm-svn: 308484
* Module::getOrInsertFunction is using C-style vararg instead of variadic ↵Serge Guelton2017-04-111-4/+2
| | | | | | | | | | | templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299949
* [CMake] Fix pthread handling for out-of-tree buildsEric Fiselier2017-02-101-1/+1
| | | | | | | | | | | | | | | LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects to correctly link the threading library when needed. Unfortunately `PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed and therefore can't be used when configuring out-of-tree builds. This causes such builds to fail since `pthread` isn't being correctly linked. This patch attempts to fix that problem by renaming and exporting `LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB` because It seemed likely to cause collisions with downstream users of `LLVMConfig.cmake`. llvm-svn: 294690
* Fix some Include What You Use warnings in examples; other minor fixes.Eugene Zelenko2016-05-251-1/+17
| | | | | | Differential revision: http://reviews.llvm.org/D20607 llvm-svn: 270645
* Refactor duplicated code for linking with pthread.Rafael Espindola2016-03-011-3/+1
| | | | llvm-svn: 262344
* Remove autoconf supportChris Bieneman2016-01-261-17/+0
| | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
* examples: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-11-071-2/+2
| | | | llvm-svn: 252379
* Fix Clang-tidy modernize-use-nullptr warnings in examples and include ↵Hans Wennborg2015-09-291-7/+8
| | | | | | | | | | directories; other minor cleanups. Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13172 llvm-svn: 248811
* llvm/examples: Add missing include according to r230907.NAKAMURA Takumi2015-03-021-0/+1
| | | | llvm-svn: 230926
* [CMake] llvm/examples: Update libdeps for unoptimized builds.NAKAMURA Takumi2014-10-311-0/+1
| | | | llvm-svn: 220962
* Fix configure and make build of llvm examples.Iain Sandoe2014-09-031-1/+1
| | | | | | Replaced link component 'jit' with 'mcjit'. llvm-svn: 217032
* Reinstate "Nuke the old JIT."Eric Christopher2014-09-022-2/+0
| | | | | | | | Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
* Make it explicit that ExecutionEngine takes ownership of the modules.Rafael Espindola2014-08-191-2/+3
| | | | llvm-svn: 215967
* Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher2014-08-072-0/+2
| | | | | | | | | | | be deleted. This will be reapplied as soon as possible and before the 3.6 branch date at any rate. Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reverts commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 215154
* Nuke the old JIT.Rafael Espindola2014-08-072-2/+0
| | | | | | | | | I am sure we will be finding bits and pieces of dead code for years to come, but this is a good start. Thanks to Lang Hames for making MCJIT a good replacement! llvm-svn: 215111
* Fix warnings about an variable only used in asserts.Ahmed Charles2014-03-061-0/+3
| | | | llvm-svn: 203089
* [CMake] Update LLVM_LINK_COMPONENTS for each CMakeLists.txt.NAKAMURA Takumi2013-12-101-1/+8
| | | | llvm-svn: 196908
* Update the examples for the new header file locations.Chandler Carruth2013-01-021-5/+5
| | | | | | | Sorry for the fallout here, I forgot the examples aren't built by default any more. llvm-svn: 171371
* Sort the #include lines of the examples/... tree.Chandler Carruth2012-12-041-6/+6
| | | | llvm-svn: 169249
* Switch to a more idiomatic way of silencing unused variable warnings inChandler Carruth2012-02-201-1/+2
| | | | | | release builds. Silences clang's -Wself-assign. llvm-svn: 150942
* Move TargetRegistry and TargetSelect from Target to Support where they belong.Evan Cheng2011-08-241-1/+1
| | | | | | These are strictly utilities for registering targets and components. llvm-svn: 138450
* Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally."Michael J. Spencer2010-09-131-2/+2
| | | | | | | | | | This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
* CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally.Michael J. Spencer2010-09-101-2/+2
| | | | llvm-svn: 113632
* Kill ModuleProvider and ghost linkage by inverting the relationship betweenJeffrey Yasskin2010-01-271-1/+0
| | | | | | | | | | | | | | | | | | | | | Modules and ModuleProviders. Because the "ModuleProvider" simply materializes GlobalValues now, and doesn't provide modules, it's renamed to "GVMaterializer". Code that used to need a ModuleProvider to materialize Functions can now materialize the Functions directly. Functions no longer use a magic linkage to record that they're materializable; they simply ask the GVMaterializer. Because the C ABI must never change, we can't remove LLVMModuleProviderRef or the functions that refer to it. Instead, because Module now exposes the same functionality ModuleProvider used to, we store a Module* in any LLVMModuleProviderRef and translate in the wrapper methods. The bindings to other languages still use the ModuleProvider concept. It would probably be worth some time to update them to follow the C++ more closely, but I don't intend to do it. Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735. llvm-svn: 94686
* Make ParallelJIT pthreads linking with CMake slightly less brokenDouglas Gregor2009-10-121-1/+3
| | | | llvm-svn: 83820
* Push LLVMContexts through the IntegerType APIs.Owen Anderson2009-08-131-12/+16
| | | | llvm-svn: 78948
* Revert the ConstantInt constructors back to their 2.5 forms where possible, ↵Owen Anderson2009-07-241-3/+3
| | | | | | thanks to contexts-on-types. More to come. llvm-svn: 77011
* Add EngineBuilder to ExecutionEngine in favor of the five optional argument ↵Reid Kleckner2009-07-181-2/+1
| | | | | | | | EE::create(). Also a test commit. llvm-svn: 76276
* Move EVER MORE stuff over to LLVMContext.Owen Anderson2009-07-141-3/+3
| | | | llvm-svn: 75703
* This started as a small change, I swear. Unfortunately, lots of things call ↵Owen Anderson2009-07-091-1/+1
| | | | | | the [I|F]CmpInst constructors. Who knew!? llvm-svn: 75200
* Hold the LLVMContext by reference rather than by pointer.Owen Anderson2009-07-011-1/+1
| | | | llvm-svn: 74640
* Add a pointer to the owning LLVMContext to Module. This requires threading ↵Owen Anderson2009-07-011-1/+3
| | | | | | | | | | LLVMContext through a lot of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools. Patches for Clang and LLVM-GCC to follow. llvm-svn: 74614
* make sure that JIT examples link in their appropriate target.Chris Lattner2009-06-171-2/+4
| | | | llvm-svn: 73613
* CMake: Builds all examples. Corrected name of CBackend target.Oscar Fuentes2008-09-261-0/+7
| | | | llvm-svn: 56682
* Remove asmprinters from examples by default. This reduces their size by ~5%Anton Korobeynikov2008-08-171-1/+1
| | | | llvm-svn: 54890
* API change for {BinaryOperator|CmpInst|CastInst}::create*() --> Create. ↵Gabor Greif2008-05-161-4/+4
| | | | | | Legacy interfaces will be in place for some time. (Merge from use-diet branch.) llvm-svn: 51200
* silence warning when assertions are disabled.Chris Lattner2008-04-081-1/+1
| | | | llvm-svn: 49371
* API changes for class Use size reduction, wave 1.Gabor Greif2008-04-061-10/+10
| | | | | | | | Specifically, introduction of XXX::Create methods for Users that have a potentially variable number of Uses. llvm-svn: 49277
* remove attributions from examples.Chris Lattner2007-12-291-2/+2
| | | | llvm-svn: 45420
* remove attributions from the rest of the llvm makefiles.Chris Lattner2007-12-291-2/+2
| | | | llvm-svn: 45416
* Adjust for changes in GenericValue type.Reid Spencer2007-03-061-2/+2
| | | | llvm-svn: 34969
* Fix a #include to resolve IntegerType class.Reid Spencer2007-01-191-1/+1
| | | | llvm-svn: 33385
* add some casts to support a change in the getOrInsertFunction interfaceChris Lattner2007-01-071-8/+8
| | | | llvm-svn: 32984
OpenPOWER on IntegriCloud