Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-03-22T18:27:13+00:00 2019-03-22T18:27:13+00:00 James Y Knight jyknight@google.com 2019-03-22T18:27:13+00:00 urn:sha1:c0e6b8ac3ad442e08d7a16382ff50969ba3f2b2d Just as as llvm IR supports explicitly specifying numeric value ids for instructions, and emits them by default in textual output, now do the same for blocks. This is a slightly incompatible change in the textual IR format. Previously, llvm would parse numeric labels as string names. E.g. define void @f() { br label %"55" 55: ret void } defined a label *named* "55", even without needing to be quoted, while the reference required quoting. Now, if you intend a block label which looks like a value number to be a name, you must quote it in the definition too (e.g. `"55":`). Previously, llvm would print nameless blocks only as a comment, and would omit it if there was no predecessor. This could cause confusion for readers of the IR, just as unnamed instructions did prior to the addition of "%5 = " syntax, back in 2008 (PR2480). Now, it will always print a label for an unnamed block, with the exception of the entry block. (IMO it may be better to print it for the entry-block as well. However, that requires updating many more tests.) Thus, the following is supported, and is the canonical printing: define i32 @f(i32, i32) { %3 = add i32 %0, %1 br label %4 4: ret i32 %3 } New test cases covering this behavior are added, and other tests updated as required. Differential Revision: https://reviews.llvm.org/D58548 llvm-svn: 356789 2019-01-29T16:37:27+00:00 James Y Knight jyknight@google.com 2019-01-29T16:37:27+00:00 urn:sha1:5d71fc5d7b5ffe2323418a09db6eddaf84d6c662 This fixes most references to the paths: llvm.org/svn/ llvm.org/git/ llvm.org/viewvc/ github.com/llvm-mirror/ github.com/llvm-project/ reviews.llvm.org/diffusion/ to instead point to https://github.com/llvm/llvm-project. This is *not* a trivial substitution, because additionally, all the checkout instructions had to be migrated to instruct users on how to use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of checking out various projects into various subdirectories. I've attempted to not change any scripts here, only documentation. The scripts will have to be addressed separately. Additionally, I've deleted one document which appeared to be outdated and unneeded: lldb/docs/building-with-debug-llvm.txt Differential Revision: https://reviews.llvm.org/D57330 llvm-svn: 352514 2019-01-21T09:52:34+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-21T09:52:34+00:00 urn:sha1:4a1b95bda0c444798a5240fe924dd127b776d12d all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. llvm-svn: 351731 2019-01-21T04:36:43+00:00 Kristina Brooks notstina@gmail.com 2019-01-21T04:36:43+00:00 urn:sha1:e67d23905f1cbcb88111b8ac7ed9f27e50bde510 Patch rL322965 changed how intrinsics for memset and memzero were defined. This causes a regression in LLGO making it no longer buidable. In addition to that one pass was renamed, so this also addresses the pass naming disparity. I removed all split stack related bits from this patch as as asked. Differential Revision: https://reviews.llvm.org/D56638 llvm-svn: 351722 2019-01-19T10:56:40+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-19T10:56:40+00:00 urn:sha1:57b08b0944046a6a57ee9b7b479181f548a5b9b4 to reflect the new license. These used slightly different spellings that defeated my regular expressions. 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: 351648 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-19T06:14:24+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-19T06:14:24+00:00 urn:sha1:469bdefd448b76c5adcdd67256e9a44fabf7e027 This installs the new developer policy and moves all of the license files across all LLVM projects in the monorepo to the new license structure. The remaining projects will be moved independently. Note that I've left odd formatting and other idiosyncracies of the legacy license structure text alone to make the diff easier to read. Critically, note that we do not in any case *remove* the old license notice or terms, as that remains necessary until we finish the relicensing process. I've updated a few license files that refer to the LLVM license to instead simply refer generically to whatever license the LLVM project is under, basically trying to minimize confusion. This is really the culmination of so many people. Chris led the community discussions, drafted the policy update and organized the multi-year string of meeting between lawyers across the community to figure out the strategy. Numerous lawyers at companies in the community spent their time figuring out initial answers, and then the Foundation's lawyer Heather Meeker has done *so* much to help refine and get us ready here. I could keep going on, but I just want to make sure everyone realizes what a huge community effort this has been from the begining. Differential Revision: https://reviews.llvm.org/D56897 llvm-svn: 351631 2019-01-15T15:10:32+00:00 Hans Wennborg hans@hanshq.net 2019-01-15T15:10:32+00:00 urn:sha1:eb60fbfdb43cb8583eda1e338b3489ddef332f10 In last year's update (D48219) it was suggested that the release manager might want to do this, so here we go. llvm-svn: 351194 2018-06-18T12:22:17+00:00 Paul Robinson paul.robinson@sony.com 2018-06-18T12:22:17+00:00 urn:sha1:7555c589af006c9c4d171794200753d0e92ef946 llvm-svn: 334936 2017-06-04T22:11:28+00:00 Peter Collingbourne peter@pcc.me.uk 2017-06-04T22:11:28+00:00 urn:sha1:08b4728f5194cd03b1100b00d4d08ac2d468a400 These are in fact functions, and have function type, so it is invalid to represent them using global variables. llvm-svn: 304689