http://llvm.org https://git.amat.us/llvm/atom/lib/ExecutionEngine/Interpreter?h=testing 2013-02-01T18:57:06Z 2013-02-01T18:57:06Z Jim Grosbach grosbach@apple.com 2013-02-01T18:57:06Z urn:sha1:9f285c6c31019f9db237932a56eff95d307fce06 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174205 91177308-0d34-0410-b5e6-96231b3b80d8 2013-01-31T19:46:59Z Jim Grosbach grosbach@apple.com 2013-01-31T19:46:59Z urn:sha1:cce07c9b3162acc756535e813e6ae818ad61564b git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174080 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 2012-11-30T03:08:41Z Chandler Carruth chandlerc@gmail.com 2012-11-30T03:08:41Z urn:sha1:84bcf93e0fd225de2217d1b712c01586a633a6d8 depends on the IR infrastructure, there is no sense in it being off in Support land. This is in preparation to start working to expand InstVisitor into more special-purpose visitors that are still generic and can be re-used across different passes. The expansion will go into the Analylis tree though as nothing in VMCore needs it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168972 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-01T09:14:31Z Chandler Carruth chandlerc@gmail.com 2012-11-01T09:14:31Z urn:sha1:426c2bf5cdd2173e4a33aea8cb92cf684a724f4b r165941: Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis. Despite this commit log, this change primarily changed stuff outside of VMCore, and those changes do not carry any tests for correctness (or even plausibility), and we have consistently found questionable or flat out incorrect cases in these changes. Most of them are probably correct, but we need to devise a system that makes it more clear when we have handled the address space concerns correctly, and ideally each pass that gets updated would receive an accompanying test case that exercises that pass specificaly w.r.t. alternate address spaces. However, from this commit, I have retained the new C API entry points. Those were an orthogonal change that probably should have been split apart, but they seem entirely good. In several places the changes were very obvious cleanups with no actual multiple address space code added; these I have not reverted when I spotted them. In a few other places there were merge conflicts due to a cleaner solution being implemented later, often not using address spaces at all. In those cases, I've preserved the new code which isn't address space dependent. This is part of my ongoing effort to clean out the partial address space code which carries high risk and low test coverage, and not likely to be finished before the 3.2 release looms closer. Duncan and I would both like to see the above issues addressed before we return to these changes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167222 91177308-0d34-0410-b5e6-96231b3b80d8 2012-10-15T16:24:29Z Micah Villmow villmow@gmail.com 2012-10-15T16:24:29Z urn:sha1:2c39b15073db81d93bb629303915b7d7e5d088dc git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165941 91177308-0d34-0410-b5e6-96231b3b80d8 2012-10-11T21:27:41Z Micah Villmow villmow@gmail.com 2012-10-11T21:27:41Z urn:sha1:fb384d61c78b60787ed65475d8403aee65023962 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165747 91177308-0d34-0410-b5e6-96231b3b80d8 2012-10-11T17:21:41Z Micah Villmow villmow@gmail.com 2012-10-11T17:21:41Z urn:sha1:f3840d2c16a4ec4c879a8ded402835746de380f8 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165726 91177308-0d34-0410-b5e6-96231b3b80d8