| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
No functional change intended, just cleaning up some code.
llvm-svn: 220187
|
|
|
|
| |
llvm-svn: 218318
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the old JIT memory manager (which does not provide any
useful functionality now that the old JIT is gone), and migrates the few
remaining clients over to SectionMemoryManager.
http://llvm.org/PR20848
llvm-svn: 218316
|
|
|
|
| |
llvm-svn: 216988
|
|
|
|
|
|
|
|
| |
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reinstates commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 216982
|
|
|
|
|
|
|
| |
Long term the idea if for the engine to not own the buffers, but for now
this is consistent with the rest of the API.
llvm-svn: 216484
|
|
|
|
| |
llvm-svn: 216427
|
|
|
|
|
|
| |
NFC.
llvm-svn: 216362
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.
Keeping this ownership would make supporting IR inside native objects
particularly painful.
This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.
This patch introduces a few new types.
* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
for convenience functions that take a filename and return both the
buffer and the Binary using that buffer.
The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.
llvm-svn: 216002
|
|
|
|
| |
llvm-svn: 215967
|
|
|
|
| |
llvm-svn: 215948
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
MSVC was complaining about Archive being an incomplete type.
llvm-svn: 214542
|
|
|
|
|
|
| |
Should fix the MSVC build.
llvm-svn: 214539
|
|
|
|
| |
llvm-svn: 214370
|
|
|
|
|
|
| |
Every user has been switched to using EngineBuilder.
llvm-svn: 213871
|
|
|
|
|
|
|
|
|
|
|
| |
ForceInterpreter=false shouldn't disable the interpreter completely because it
can still be necessary to interpret if the target doesn't support JIT.
No obvious way to test this in LLVM, but this matches what
LLVMCreateExecutionEngineForModule() does and fixes the clang-interpreter
example in the clang source tree which uses the ExecutionEngine.
llvm-svn: 212086
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 1f502bd9d7d2c1f98ad93a09ffe435e11a95aedd, due to
GCC / MinGW's lack of support for C++11 threading.
It's possible this will go back in after we come up with a
reasonable solution.
llvm-svn: 211401
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change has a bit of a trickle down effect due to the fact that
there are a number of derived implementations of ExecutionEngine,
and that the mutex is not tightly encapsulated so is used by other
classes directly.
Reviewed by: rnk
Differential Revision: http://reviews.llvm.org/D4196
llvm-svn: 211214
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were being used as unreferenced parameters to enforce that
the methods must not be called without holding a mutex, but all
of the methods in question were internal, and the methods were
only exposed through an interface whose entire purpose was to
serialize access to these structures, so expecting the methods
to be accessed under a mutex is reasonable enough.
Reviewed by: blaikie
Differential Revision: http://reviews.llvm.org/D4162
llvm-svn: 211054
|
|
|
|
| |
llvm-svn: 209981
|
|
|
|
| |
llvm-svn: 208346
|
|
|
|
|
|
|
|
| |
Seems MSVC wants to be able to codegen inline-definitions of virtual
functions even in TUs that don't define the key function - and it's well
within its rights to do so.
llvm-svn: 207581
|
|
|
|
|
|
|
| |
definition below all the header #include lines. This updates most of the
miscellaneous other lib/... directories. A few left though.
llvm-svn: 206845
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously module verification was always enabled, with no way to turn it off.
As of this commit, module verification is on by default in Debug builds, and off
by default in release builds. The default behaviour can be overridden by calling
setVerifyModules(bool) on the JIT instance (this works for both the old JIT, and
MCJIT).
<rdar://problem/16150008>
llvm-svn: 206561
|
|
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206252
|
|
|
|
|
|
| |
class.
llvm-svn: 203344
|
|
|
|
|
|
|
|
|
|
| |
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
llvm-svn: 203083
|
|
|
|
| |
llvm-svn: 202957
|
|
|
|
|
|
|
|
|
|
|
| |
Move the test for this class into the IR unittests as well.
This uncovers that ValueMap too is in the IR library. Ironically, the
unittest for ValueMap is useless in the Support library (honestly, so
was the ValueHandle test) and so it already lives in the IR unittests.
Mmmm, tasty layering.
llvm-svn: 202821
|
|
|
|
|
|
| |
TargetData was renamed DataLayout back in r165242.
llvm-svn: 201581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.
Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:
define available_externally dllimport void @f() {}
@Var = dllexport global i32 1, align 4
Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.
llvm-svn: 199218
|
|
|
|
|
|
|
|
| |
Revert this for now until I fix an issue in Clang with it.
This reverts commit r199204.
llvm-svn: 199207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.
Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:
define available_externally dllimport void @f() {}
@Var = dllexport global i32 1, align 4
Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.
llvm-svn: 199204
|
|
|
|
|
|
|
|
|
|
| |
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
llvm-svn: 198685
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 195064
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
llvm-svn: 194997
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 194865
|
|
|
|
|
|
|
|
| |
ExecutionEngine.
Patch by Dale Martin!
llvm-svn: 194831
|
|
|
|
|
|
|
|
|
| |
Support for exception handling in the legacy JIT was removed in r181354 and
this code was dead since then.
Thanks to Yaron Keren for noticing it.
llvm-svn: 192101
|
|
|
|
|
|
|
|
| |
undef constatnt for structure and test for these functions.
done by Yuri Veselov (mailto:Yuri.Veselov@intel.com)
llvm-svn: 190599
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EngineBuilder interface required a JITMemoryManager even if it was being used
to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager.
Consequently, the SectionMemoryManager, which is meant for MCJIT, derived
from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager
methods that weren't relevant to the MCJIT.
This patch fixes the situation: it teaches the EngineBuilder that
RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's
appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if
we're using the MCJIT. This allows us to remove the stub methods from
SectionMemoryManager, and make SectionMemoryManager a direct subtype of
RTDyldMemoryManager.
llvm-svn: 181820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I will remove the isBigEndianHost function once I update clang.
The ifdef logic is designed to
* not use configure/cmake to avoid breaking -arch i686 -arch ppc.
* default to little endian
* be as small as possible
It looks like sys/endian.h is the preferred header on most modern BSD systems,
but it is better to change this in a followup patch as machine/endian.h is
available on FreeBSD, OpenBSD, NetBSD and OS X.
llvm-svn: 179527
|
|
|
|
|
|
|
| |
Patch by:
Veselov, Yuri <Yuri.Veselov@intel.com>
llvm-svn: 178469
|
|
|
|
|
|
|
|
|
| |
Previously we tried to infer it from the bit width size, with an added
IsIEEE argument for the PPC/IEEE 128-bit case, which had a default
value. This default value allowed bugs to creep in, where it was
inappropriate.
llvm-svn: 173138
|
|
|
|
|
|
| |
Do proper casting to eliminate a const-away-cast compiler warning.
llvm-svn: 172470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
GEP::accumulateConstantOffset().
The later API is nicer than the former, and is correct regarding wrap-around offsets (if anyone cares).
There are a few more places left with duplicated code, which I'll remove soon.
llvm-svn: 171259
|