aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ExecutionEngine/ExecutionEngine.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-11-28[llvm] Use range-based for loops (NFC)Kazu Hirata1-2/+1
2021-10-08Move TargetRegistry.(h|cpp) from Support to MCReid Kleckner1-1/+1
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support. This allows us to ensure that Support doesn't have includes from MC/*. Differential Revision: https://reviews.llvm.org/D111454
2020-10-18[ORC] Remove OrcV1 APIs.Lang Hames1-13/+2
This removes all legacy layers, legacy utilities, the old Orc C bindings, OrcMCJITReplacement, and OrcMCJITReplacement regression tests. ExecutionEngine and MCJIT are not affected by this change.
2020-06-30[SVE] Remove calls to VectorType::getNumElements from ExecutionEngineChristopher Tetreault1-10/+18
Reviewers: efriedma, lhames, sdesmalen, fpetrogalli Reviewed By: lhames, sdesmalen Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82211
2020-06-29[Alignment][NFC] migrate DataLayout::getPreferredAlignmentGuillaume Chatelet1-1/+1
This patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Differential Revision: https://reviews.llvm.org/D82752
2020-04-22[SVE] Add new VectorType subclassesChristopher Tetreault1-16/+19
Summary: Introduce new types for fixed width and scalable vectors. Does not remove getNumElements yet so as to not break code during transition period. Reviewers: deadalnix, efriedma, sdesmalen, craig.topper, huntergr Reviewed By: sdesmalen Subscribers: jholewinski, arsenm, jvesely, nhaehnle, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, liufengdb, kerbowa, Joonsoo, grosul1, frgossen, lldb-commits, tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm, #lldb Differential Revision: https://reviews.llvm.org/D77587
2020-02-13[AsmPrinter] De-capitalize all AsmPrinter::Emit* but EmitInstructionFangrui Song1-3/+3
Similar to rL328848.
2020-01-29Another round of GCC5 fixes.Benjamin Kramer1-2/+2
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-13/+13
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.
2019-09-16[ExecutionEngine] Don't dereference a dyn_cast result. NFCI.Simon Pilgrim1-2/+2
The static analyzer is warning about potential null dereferences of dyn_cast<> results - in these cases we can safely use cast<> directly as we know that these cases should all be the correct type, which is why its working atm and anyway cast<> will assert if they aren't. llvm-svn: 371998
2019-08-15[llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-2/+2
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
2019-08-07Replace llvm::MutexGuard/UniqueLock with their standard equivalentsBenjamin Kramer1-13/+13
All supported platforms have <mutex> now, so we don't need our own copies any longer. No functionality change intended. llvm-svn: 368149
2019-07-02[C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington1-53/+0
This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a bit_cast from a value v to a type T. This expression can be evaluated at compile time under specific circumstances. The compile time evaluation currently doesn't support bit-fields, but I'm planning on fixing this in a follow up (some of the logic for figuring this out is in CodeGen). I'm also planning follow-ups for supporting some more esoteric types that the constexpr evaluator supports, as well as extending __builtin_memcpy constexpr evaluation to use the same infrastructure. rdar://44987528 Differential revision: https://reviews.llvm.org/D62825 llvm-svn: 364954
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-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
2018-05-24Add handling for GlobalAliases in ExecutionEngine::getConstantValue.Lang Hames1-0/+3
Patch by Brad Moody. Thanks Brad! https://reviews.llvm.org/D42160 llvm-svn: 333217
2018-05-14Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen1-6/+7
The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
2018-05-01Remove \brief commands from doxygen comments.Adrian Prantl1-3/+3
We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2018-01-19[ORC] Re-apply r322913 with a fix for a read-after-free error.Lang Hames1-8/+7
ExternalSymbolMap now stores the string key (rather than using a StringRef), as the object file backing the key may be removed at any time. llvm-svn: 323001
2018-01-19[ORC] Revert r322913 while I investigate an ASan failure.Lang Hames1-7/+8
llvm-svn: 322914
2018-01-19[ORC] Redesign the JITSymbolResolver interface to support bulk queries.Lang Hames1-8/+7
Bulk queries reduce IPC/RPC overhead for cross-process JITing and expose opportunities for parallel compilation. The two new query methods are lookupFlags, which finds the flags for each of a set of symbols; and lookup, which finds the address and flags for each of a set of symbols. (See doxygen comments for more details.) The existing JITSymbolResolver class is renamed LegacyJITSymbolResolver, and modified to extend the new JITSymbolResolver class using the following scheme: - lookupFlags is implemented by calling findSymbolInLogicalDylib for each of the symbols, then returning the result of calling getFlags() on each of these symbols. (Importantly: lookupFlags does NOT call getAddress on the returned symbols, so lookupFlags will never trigger materialization, and lookupFlags will never call findSymbol, so only symbols that are part of the logical dylib will return results.) - lookup is implemented by calling findSymbolInLogicalDylib for each symbol and falling back to findSymbol if findSymbolInLogicalDylib returns a null result. Assuming a symbol is found its getAddress method is called to materialize it and the result (if getAddress succeeds) is stored in the result map, or the error (if getAddress fails) is returned immediately from lookup. If any symbol is not found then lookup returns immediately with an error. This change will break any out-of-tree derivatives of JITSymbolResolver. This can be fixed by updating those classes to derive from LegacyJITSymbolResolver instead. llvm-svn: 322913
2018-01-10[ExecutionEngine] Remove an unused variable.Lang Hames1-1/+0
Patch by Evgeniy Tyurin. Thanks Evgeniy! Review: https://reviews.llvm.org/D41431 llvm-svn: 322158
2017-08-03Delete Default and JITDefault code modelsRafael Espindola1-1/+1
IMHO it is an antipattern to have a enum value that is Default. At any given piece of code it is not clear if we have to handle Default or if has already been mapped to a concrete value. In this case in particular, only the target can do the mapping and it is nice to make sure it is always done. This deletes the two default enum values of CodeModel and uses an explicit Optional<CodeModel> when it is possible that it is unspecified. llvm-svn: 309911
2017-03-20Use MutableArrayRef for APFloat::convertToIntegerSimon Pilgrim1-1/+1
As discussed on D31074, use MutableArrayRef for destination integer buffers to help assert before stack overflows happen. llvm-svn: 298253
2017-03-20Strip trailing whitespaceSimon Pilgrim1-8/+8
llvm-svn: 298248
2016-12-14Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann1-3/+3
At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
2016-10-01Use StringRef instead of raw pointer in ExecutionEngineMehdi Amini1-3/+3
llvm-svn: 283016
2016-09-04[ExecutionEngine] Move ObjectCache::anchor from MCJIT to ExecutionEngine.Lang Hames1-0/+3
ObjectCache is an ExecutionEngine utility, so its anchor belongs there. The practical impact of this change is that ORC users no longer need to link MCJIT to use ObjectCaches. llvm-svn: 280616
2016-08-01[ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames1-4/+5
This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class that is capable of lazy materialization (i.e. the symbol definition needn't be emitted until the address is requested). This can be used to support common and weak symbols in the JIT (though this is not implemented in this patch). For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver. For space efficiency a new class, JITEvaluatedSymbol, is introduced that behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an address and symbol flags. Instances of JITEvaluatedSymbol can be used in symbol-tables to avoid paying the space cost of the materializer. llvm-svn: 277386
2016-06-22IR: Introduce Module::global_objects().Peter Collingbourne1-4/+2
This is a convenience iterator that allows clients to enumerate the GlobalObjects within a Module. Also start using it in a few places where it is obviously the right thing to use. Differential Revision: http://reviews.llvm.org/D21580 llvm-svn: 273470
2016-05-18Delete Reloc::Default.Rafael Espindola1-2/+1
Having an enum member named Default is quite confusing: Is it distinct from the others? This patch removes that member and instead uses Optional<Reloc> in places where we have a user input that still hasn't been maped to the default value, which is now clear has no be one of the remaining 3 options. llvm-svn: 269988
2016-01-16GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob1-2/+2
Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
2016-01-14Update to use new name alignTo().Rui Ueyama1-3/+1
llvm-svn: 257804
2015-10-13ExecutionEngine: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith1-5/+4
llvm-svn: 250193
2015-09-21Remove roundingMode argument in APFloat::modStephen Canon1-2/+1
Because mod is always exact, this function should have never taken a rounding mode argument. The actual implementation still has issues, which I'll look at resolving in a subsequent patch. llvm-svn: 248195
2015-08-03-Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are ↵David Blaikie1-1/+1
deprecated in C++11 Various value handles needed to be copy constructible and copy assignable (mostly for their use in DenseMap). But to avoid an API that might allow accidental slicing, make these members protected in the base class and make derived classes final (the special members become implicitly public there - but disallowing further derived classes that might be sliced to the intermediate type). Might be worth having a warning a bit like -Wnon-virtual-dtor that catches public move/copy assign/ctors in classes with virtual functions. (suppressable in the same way - by making them protected in the base, and making the derived classes final) Could be fancier and only diagnose them when they're actually called, potentially. Also allow a few default implementations where custom implementations (especially with non-standard return types) were implemented. llvm-svn: 243909
2015-08-01De-constify pointers to Type since they can't be modified. NFCCraig Topper1-4/+4
This was already done in most places a while ago. This just fixes the ones that crept in over time. llvm-svn: 243842
2015-07-29[MCJIT] Fix PR20656 by teaching MCJIT to honor ExecutionEngine's global mapping.Lang Hames1-2/+9
This is important for users of the C API who can't supply custom symbol resolvers yet. llvm-svn: 243589
2015-07-16Make ExecutionEngine owning a DataLayoutMehdi Amini1-18/+27
Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. The ExecutionEngine will act as an exception and will be unsafe to be reused across context. We don't enforce this rule but undefined behavior can occurs if the user tries to do it. Reviewers: lhames Subscribers: echristo, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11110 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 242414
2015-07-16Revert "Make ExecutionEngine owning a DataLayout"Michael Kuperstein1-18/+18
Reverting to fix buildbot breakage. This reverts commit r242387. llvm-svn: 242394
2015-07-16Make ExecutionEngine owning a DataLayoutMehdi Amini1-18/+18
Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. The ExecutionEngine will act as an exception and will be unsafe to be reused across context. We don't enforce this rule but undefined behavior can occurs if the user tries to do it. Reviewers: lhames Subscribers: echristo, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11110 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 242387
2015-06-23Simplify the Mangler interface now that DataLayout is mandatory.Rafael Espindola1-2/+2
We only need to pass in a DataLayout when mangling a raw string, not when constructing the mangler. llvm-svn: 240405
2015-06-20[MCJIT] Add a FindGlobalVariableNamed utilityKeno Fischer1-0/+8
Summary: This adds FindGlobalVariableNamed to ExecutionEngine (plus implementation in MCJIT), which is an analog of FindFunctionNamed for GlobalVariables. Reviewers: lhames Reviewed By: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10421 llvm-svn: 240202
2015-06-13[ExecutionEngine] ArrayRefize argument passing.Benjamin Kramer1-1/+1
No functionality change intended. llvm-svn: 239687
2015-05-29Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer1-1/+1
If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238602
2015-03-31[ExecutionEngine] Fix MCJIT::addGlobalMapping.Lang Hames1-58/+81
This patch fixes MCJIT::addGlobalMapping by changing the implementation of the ExecutionEngineState class. The new implementation maintains a bidirectional mapping between symbol names (std::strings) and addresses (uint64_ts), rather than a mapping between Value*s and void*s. This has fix has been made for backwards compatibility, however the strongly preferred way to resolve unknown symbols is by writing a custom RuntimeDyld::SymbolResolver (formerly RTDyldMemoryManager) and overriding the findSymbol method. The addGlobalMapping method is a hangover from the legacy JIT (which has was removed in 3.6), and may be deprecated in a future release as part of a clean-up of the ExecutionEngine interface. Patch by Murat Bolat. Thanks Murat! llvm-svn: 233747
2015-03-30[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo throughLang Hames1-9/+28
MCJIT. This patch decouples the two responsibilities of the RTDyldMemoryManager class, memory management and symbol resolution, into two new classes: RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver. The symbol resolution interface is modified slightly, from: uint64_t getSymbolAddress(const std::string &Name); to: RuntimeDyld::SymbolInfo findSymbol(const std::string &Name); The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld and others to reason about non-strong/non-exported symbols. The memory management interface removes the following method: void notifyObjectLoaded(ExecutionEngine *EE, const object::ObjectFile &) {} as it is not related to memory management. (Note: Backwards compatibility *is* maintained for this method in MCJIT and OrcMCJITReplacement, see below). The RTDyldMemoryManager class remains in-tree for backwards compatibility. It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which just subclasses RuntimeDyld::MemoryManager and reintroduces the notifyObjectLoaded method for backwards compatibility). The EngineBuilder class retains the existing method: EngineBuilder& setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm); and includes two new methods: EngineBuilder& setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM); EngineBuilder& setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR); Clients should use EITHER: A single call to setMCJITMemoryManager with an RTDyldMemoryManager. OR (exclusive) One call each to each of setMemoryManager and setSymbolResolver. This patch should be fully compatible with existing uses of RTDyldMemoryManager. If it is not it should be considered a bug, and the patch either fixed or reverted. If clients find the new API to be an improvement the goal will be to deprecate and eventually remove the RTDyldMemoryManager class in favor of the new classes. llvm-svn: 233509
2015-03-06Fold init() helpers into constructors. NFC.Benjamin Kramer1-25/+12
llvm-svn: 231486
2015-03-01Add missing includes. make_unique proliferated everywhere.Benjamin Kramer1-0/+1
llvm-svn: 230909
2015-01-27[ExecutionEngine] FindFunctionNamed: Skip declarationsKeno Fischer1-1/+2
Summary: Basically all other methods that look up functions by name skip them if they are mere declarations. Do the same in FindFunctionNamed. Reviewers: lhames Reviewed By: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7068 llvm-svn: 227227
2015-01-23[Orc] New JIT APIs.Lang Hames1-1/+16
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to cleanly support a wider range of JIT use cases in LLVM, and encourage the development and contribution of re-usable infrastructure for LLVM JIT use-cases. These APIs are intended to live alongside the MCJIT APIs, and should not affect existing clients. Included in this patch: 1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of components for building JIT infrastructure. Implementation code for these headers lives in lib/ExecutionEngine/Orc. 2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the new components. 3) Minor changes to RTDyldMemoryManager needed to support the new components. These changes should not impact existing clients. 4) A new flag for lli, -use-orcmcjit, which will cause lli to use the OrcMCJITReplacement class as its underlying execution engine, rather than MCJIT itself. Tests to follow shortly. Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher, Justin Bogner, and Jim Grosbach for extensive feedback and discussion. llvm-svn: 226940
generated by cgit v1.1 at 2025-10-04 08:56:09 +0000