llvm/lib/ExecutionEngine/Interpreter, branch release_30http://llvm.orghttps://git.amat.us/llvm/atom/lib/ExecutionEngine/Interpreter?h=release_302011-09-29T20:21:17ZClean up uses of switch instructions so they are not dependent on the operand ordering. Patch by Stepan Dyatkovskiy.2011-09-29T20:21:17ZEli Friedmaneli.friedman@gmail.com2011-09-29T20:21:17Zurn:sha1:bb5a7442e362776621112dc9453e546a55878e79
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140803 91177308-0d34-0410-b5e6-96231b3b80d8
Don't tack "Instruction not interpretable yet!" onto the end of2011-09-09T20:22:48ZDuncan Sandsbaldrick@free.fr2011-09-09T20:22:48Zurn:sha1:a50c6d95e492590c14e5ace8c3e2e1de8bf5e80e
the instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139398 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite the CMake build to use explicit dependencies between libraries,2011-07-29T00:14:25ZChandler Carruthchandlerc@gmail.com2011-07-29T00:14:25Zurn:sha1:ac03e736c77bcf7e8deb515fc16a7e55d343dc8d
specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.
I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.
This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.
This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.
Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.
This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136433 91177308-0d34-0410-b5e6-96231b3b80d8
land David Blaikie's patch to de-constify Type, with a few tweaks.2011-07-18T04:54:35ZChris Lattnersabre@nondot.org2011-07-18T04:54:35Zurn:sha1:db125cfaf57cc83e7dd7453de2d509bc8efd0e5e
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135375 91177308-0d34-0410-b5e6-96231b3b80d8
Land the long talked about "type system rewrite" patch. This2011-07-09T17:41:24ZChris Lattnersabre@nondot.org2011-07-09T17:41:24Zurn:sha1:1afcace3a3a138b1b18e5c6270caa8dae2261ae2
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
eliminate the Type::getDescription() method, using "<<" instead. This 2011-06-18T21:18:23ZChris Lattnersabre@nondot.org2011-06-18T21:18:23Zurn:sha1:0cd0d881604775f3f97048645f040b2ef4f61e4b
removes some gunk from LLVMContext.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133360 91177308-0d34-0410-b5e6-96231b3b80d8
Fix libffi usage when it is on a custom path.2011-01-28T16:49:05ZOscar Fuentesofv@wanadoo.es2011-01-28T16:49:05Zurn:sha1:abcae24d991844ac6ac33b773b1007e2e901575c
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124486 91177308-0d34-0410-b5e6-96231b3b80d8
Use the paths to libffi's header and library even when no custom2011-01-27T22:58:34ZOscar Fuentesofv@wanadoo.es2011-01-27T22:58:34Zurn:sha1:11d23bd8906186713a8ef3568724219626e400cc
location was stated with FFI_INCLUDE_DIR/FFI_LIBRARY_DIR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124449 91177308-0d34-0410-b5e6-96231b3b80d8
Handles libffi on the CMake build.2011-01-21T15:42:54ZOscar Fuentesofv@wanadoo.es2011-01-21T15:42:54Zurn:sha1:596937914548c181f2504aad3b709189e87a561b
Patch by arrowdodger!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123976 91177308-0d34-0410-b5e6-96231b3b80d8
Merge System into Support.2010-11-29T18:16:10ZMichael J. Spencerbigcheesegs@gmail.com2010-11-29T18:16:10Zurn:sha1:1f6efa3996dd1929fbc129203ce5009b620e6969
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120298 91177308-0d34-0410-b5e6-96231b3b80d8