LLVM with the emscripten fastcomp javascript backend https://git.amat.us/emscripten-fastcomp/atom/lib/ExecutionEngine/MCJIT?h=master 2013-05-05T20:43:10Z 2013-05-05T20:43:10Z Rafael Espindola rafael.espindola@gmail.com 2013-05-05T20:43:10Z urn:sha1:a2e40fbd624916c187a95ed76939ca7f02ed3e53 This gets exception handling working on ELF and Macho (x86-64 at least). Other than the EH frame registration, this patch also implements support for GOT relocations which are used to locate the personality function on MachO. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181167 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-01T22:58:00Z Filip Pizlo fpizlo@apple.com 2013-05-01T22:58:00Z urn:sha1:0e1327e4aa1426aaa3f99a2cbfcb1f2b575791ad CodeModel: It's now possible to create an MCJIT instance with any CodeModel you like. Previously it was only possible to create an MCJIT that used CodeModel::JITDefault. EnableFastISel: It's now possible to turn on the fast instruction selector. The CodeModel option required some trickery. The problem is that previously, we were ensuring future binary compatibility in the MCJITCompilerOptions by mandating that the user bzero's the options struct and passes the sizeof() that he saw; the bindings then bzero the remaining bits. This works great but assumes that the bitwise zero equivalent of any field is a sensible default value. But this is not the case for LLVMCodeModel, or its internal equivalent, llvm::CodeModel::Model. In both of those, the default for a JIT is CodeModel::JITDefault (or LLVMCodeModelJITDefault), which is not bitwise zero. Hence this change introduces LLVMInitializeMCJITCompilerOptions(), which will initialize the user's options struct with defaults. The user will use this in the same way that they would have previously used memset() or bzero(). MCJITCAPITest.cpp illustrates the change, as does the comment in ExecutionEngine.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180893 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-29T17:49:40Z Andrew Kaylor andrew.kaylor@intel.com 2013-04-29T17:49:40Z urn:sha1:d2755af8bda2e0fd80efb46556485c4cdbe8704a Re-submitting with fix for OCaml dependency problems (removing dependency on SectionMemoryManager when it isn't used). Patch by Fili Pizlo git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180720 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-25T21:02:36Z Andrew Kaylor andrew.kaylor@intel.com 2013-04-25T21:02:36Z urn:sha1:1c489455ea5fac43a5f20911dfb5486630eb0160 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180575 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-25T03:47:41Z Rafael Espindola rafael.espindola@gmail.com 2013-04-25T03:47:41Z urn:sha1:06fd5bf4ea122960f0435449c2391ea4fe1ea2ca This reverts commit 07f03923137a91e3cca5d7fc075a22f8c9baf33a. Looks like it broke the valgrind bot: http://lab.llvm.org:8011/builders/llvm-x86_64-linux-vg_leak/builds/649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180249 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-24T22:39:12Z Andrew Kaylor andrew.kaylor@intel.com 2013-04-24T22:39:12Z urn:sha1:034f4be273f0ec629da4bc8369578fc195f3212f git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180225 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-23T21:26:38Z Andrew Kaylor andrew.kaylor@intel.com 2013-04-23T21:26:38Z urn:sha1:07f03923137a91e3cca5d7fc075a22f8c9baf33a git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180146 91177308-0d34-0410-b5e6-96231b3b80d8 2013-01-02T11:36:10Z Chandler Carruth chandlerc@gmail.com 2013-01-02T11:36:10Z urn:sha1:0b8c9a80f20772c3793201ab5b251d3520b9cea3 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8 2012-12-04T07:12:27Z Chandler Carruth chandlerc@gmail.com 2012-12-04T07:12:27Z urn:sha1:a1514e24cc24b050f53a12650e047799358833a1 missed in the first pass because the script didn't yet handle include guards. Note that the script is now able to handle all of these headers without manual edits. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169224 91177308-0d34-0410-b5e6-96231b3b80d8 2012-12-03T16:50:05Z Chandler Carruth chandlerc@gmail.com 2012-12-03T16:50:05Z urn:sha1:d04a8d4b33ff316ca4cf961e06c9e312eff8e64f Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8