Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-01-19T08:50:56+00:00 2019-01-19T08:50:56+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-19T08:50:56+00:00 urn:sha1:2946cd701067404b99c39fb29dc9c74bd7193eb3 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 2019-01-14T18:25:35+00:00 Tom Stellard tstellar@redhat.com 2019-01-14T18:25:35+00:00 urn:sha1:d0a767608773cfa3d8644c27796b63ff40962806 Summary: This patch drops install targets for LLVMHello.so, TestPlugin.so, and BugpointPasses.so. Reviewers: chandlerc, beanz, thakis, philip.pfaffe Reviewed By: chandlerc Subscribers: SquallATF, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D55965 llvm-svn: 351087 2018-12-20T22:04:08+00:00 Tom Stellard tstellar@redhat.com 2018-12-20T22:04:08+00:00 urn:sha1:2f44fbe936fab72921c3daa41fc8bf8f491c55be Summary: This function is very similar to add_llvm_library(), so this patch merges it into add_llvm_library() and replaces all calls to add_llvm_loadable_module(lib ...) with add_llvm_library(lib MODULE ...) Reviewers: philip.pfaffe, beanz, chandlerc Reviewed By: philip.pfaffe Subscribers: chapuni, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D51748 llvm-svn: 349839 2016-05-26T11:16:43+00:00 John Brawn john.brawn@arm.com 2016-05-26T11:16:43+00:00 urn:sha1:3546c2f1583a0d57fed3ef14d6cf28957c3c642f The problem with plugins on Windows is that when building a plugin DLL it needs to explicitly link against something (an exe or DLL) if it uses symbols from that thing, and that thing must explicitly export those symbols. Also there's a limit of 65535 symbols that can be exported. This means that currently plugins only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with MSVC. This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled automatically exports from all LLVM tools the symbols that a plugin could want to use so that a plugin can link against a tool directly. Plugins can specify what tool they link against by using PLUGIN_TOOL argument to llvm_add_library. The option can also be enabled on Linux, though there all it should do is restrict the set of symbols that are exported as by default all symbols are exported. This option is currently OFF by default, as while I've verified that it works with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no idea what will happen on OSX. Also unfortunately we can't turn on LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be loaded by both bugpoint.exe and opt.exe which is incompatible with this approach. Also currently clang plugins don't work with this approach, which will be fixed in future patches. Differential Revision: http://reviews.llvm.org/D18826 llvm-svn: 270839 2016-01-26T21:29:08+00:00 Chris Bieneman beanz@apple.com 2016-01-26T21:29:08+00:00 urn:sha1:e49730d4baa8443ad56f59bd8066bf4c1e56ea72 Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861 2015-06-23T09:49:53+00:00 Alexander Kornienko alexfh@google.com 2015-06-23T09:49:53+00:00 urn:sha1:f00654e31b984a8021db6444537093121607d8cf Apparently, the style needs to be agreed upon first. llvm-svn: 240390 2015-06-19T15:57:42+00:00 Alexander Kornienko alexfh@google.com 2015-06-19T15:57:42+00:00 urn:sha1:70bc5f1398c2d4fbfa4f5ae524b5514f3abe12b5 The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137 2015-06-16T00:44:12+00:00 Duncan P. N. Exon Smith dexonsmith@apple.com 2015-06-16T00:44:12+00:00 urn:sha1:51149d558953695f1fd9654496eddf38f0617677 `LLVM_ENABLE_MODULES` builds sometimes fail because `Intrinsics.td` needs to regenerate `Instrinsics.h` before anyone can include anything from the LLVM_IR module. Represent the dependency explicitly to prevent that. llvm-svn: 239796 2014-07-13T13:36:48+00:00 NAKAMURA Takumi geek4civic@gmail.com 2014-07-13T13:36:48+00:00 urn:sha1:c4fc6eec53400afacfd3f946b0a546bfe9a4c5a9 llvm-svn: 212904 2014-04-22T02:55:47+00:00 Chandler Carruth chandlerc@gmail.com 2014-04-22T02:55:47+00:00 urn:sha1:964daaaf192f76eccb4eb9fed849133c91b96bc5 definition below all of the header #include lines, lib/Transforms/... edition. This one is tricky for two reasons. We again have a couple of passes that define something else before the includes as well. I've sunk their name macros with the DEBUG_TYPE. Also, InstCombine contains headers that need DEBUG_TYPE, so now those headers #define and #undef DEBUG_TYPE around their code, leaving them well formed modular headers. Fixing these headers was a large motivation for all of these changes, as "leaky" macros of this form are hard on the modules implementation. llvm-svn: 206844