Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-15T03:46:52+00:00 2020-01-15T03:46:52+00:00 Tom Stellard tstellar@redhat.com 2020-01-15T03:15:07+00:00 urn:sha1:0dbcb3639451a7c20e2d5133b459552281e64455 Summary: For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF this change makes all symbols in the target specific libraries hidden by default. A new macro called LLVM_EXTERNAL_VISIBILITY has been added to mark symbols in these libraries public, which is mainly needed for the definitions of the LLVMInitialize* functions. This patch reduces the number of public symbols in libLLVM.so by about 25%. This should improve load times for the dynamic library and also make abi checker tools, like abidiff require less memory when analyzing libLLVM.so One side-effect of this change is that for builds with LLVM_BUILD_LLVM_DYLIB=ON and LLVM_LINK_LLVM_DYLIB=ON some unittests that access symbols that are no longer public will need to be statically linked. Before and after public symbol counts (using gcc 8.2.1, ld.bfd 2.31.1): nm before/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 36221 nm after/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 26278 Reviewers: chandlerc, beanz, mgorny, rnk, hans Reviewed By: rnk, hans Subscribers: merge_guards_bot, luismarques, smeenai, ldionne, lenary, s.egerton, pzheng, sameer.abuasal, MaskRay, wuzish, echristo, Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, kristina, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D54439 2020-01-07T10:55:38+00:00 Simon Pilgrim llvm-dev@redking.me.uk 2020-01-06T18:24:53+00:00 urn:sha1:bcb47bbd7214b2795eb114df22ef745850abccb2 2020-01-07T04:44:14+00:00 Fangrui Song maskray@google.com 2020-01-03T20:02:46+00:00 urn:sha1:3d87d0b925713effb108a387924562211ecbf2be Follow-up of D72172. Reviewed By: jhenderson, rnk Differential Revision: https://reviews.llvm.org/D72180 2020-01-07T04:42:22+00:00 Fangrui Song maskray@google.com 2020-01-03T18:55:30+00:00 urn:sha1:aa708763d30384c0da0b0779be96ba45f65773df printInst prints a branch/call instruction as `b offset` (there are many variants on various targets) instead of `b address`. It is a convention to use address instead of offset in most external symbolizers/disassemblers. This difference makes `llvm-objdump -d` output unsatisfactory. Add `uint64_t Address` to printInst(), so that it can pass the argument to printInstruction(). `raw_ostream &OS` is moved to the last to be consistent with other print* methods. The next step is to pass `Address` to printInstruction() (generated by tablegen from the instruction set description). We can gradually migrate targets to print addresses instead of offsets. In any case, downstream projects which don't know `Address` can pass 0 as the argument. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72172 2019-12-05T09:29:26+00:00 Florian Hahn flo@fhahn.com 2019-12-05T09:16:08+00:00 urn:sha1:76a5c8421e04b246892157fe18f1c082c908c5e9 This patch adds forward iterators mc_difflist_iterator, mc_subreg_iterator and mc_superreg_iterator, based on the existing DiffListIterator. Those are used to provide iterator ranges over sub- and super-register from TRI, which are slightly more convenient than the existing MCSubRegIterator/MCSuperRegIterator. Unfortunately, it duplicates a bit of functionality, but the new iterators are a bit more convenient (and can be used with various existing iterator utilities) and should probably replace the old iterators in the future. This patch updates some existing users. Reviewers: evandro, qcolombet, paquette, MatzeB, arsenm Reviewed By: qcolombet Differential Revision: https://reviews.llvm.org/D70565 2019-11-26T21:43:25+00:00 Simon Atanasyan simon@atanasyan.com 2019-11-21T22:33:46+00:00 urn:sha1:11074bfffee022fbbdca177a96dc2eaf2df6d936 There are a couple of bugs with the sc, scs, ll, lld instructions expanding: 1. On R6 these instruction pack immediate offset into a 9-bit field. Now if an immediate exceeds 9-bits assembler does not perform expansion and just rejects such instruction. 2. On 64-bit non-PIC code if an operand is a symbol assembler generates incorrect sequence of instructions. It uses R_MIPS_HI16 and R_MIPS_LO16 relocations and skips R_MIPS_HIGHEST and R_MIPS_HIGHER ones. To solve these problems this patch: - Introduces `mem_simm9_exp` to mark 9-bit memory immediate operands which require expansion. Probably later all `mem_simm9` operands will be able to migrate on `mem_simm9_exp` and we rename it to `mem_simm9`. - Adds new `OPERAND_MEM_SIMM9` operand type and assigns it to the `mem_simm9_exp`. That allows to know operand size in the `processInstruction` method and decide whether we need to expand instruction. - Adds `expandMem9Inst` method to expand instructions with 9-bit memory immediate operand. This method just load immediate into a "base" register used by origibal instruction: sc $2, 256($sp) => addiu $1, $sp, 256 sc $2, 0($1) - Fix `expandMem16Inst` to support a correct set of relocations for symbol loading in case of 64-bit non-PIC code. ll $12, symbol => lui $12, 0 R_MIPS_HIGHEST symbol daddiu $12, $12, 0 R_MIPS_HIGHER symbol dsll $12, $12, 16 daddiu $12, $12, 0 R_MIPS_HI16 symbol dsll $12, $12, 16 ll $12, 0($12) R_MIPS_LO16 symbol - Fix `expandMem16Inst` to unify handling of 3 and 4 operands instructions. - Delete unused now `MipsTargetStreamer::emitSCWithSymOffset` method. Task for next patches - implement expanding for other instructions use `mem_simm9` operand and other `mem_simm##` operands. Differential Revision: https://reviews.llvm.org/D70648 2019-11-21T18:48:08+00:00 Tom Stellard tstellar@redhat.com 2019-11-14T05:39:58+00:00 urn:sha1:ab411801b82783eb7f652701ccfce81b16cf1811 Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179 2019-11-21T10:50:14+00:00 Simon Atanasyan simon@atanasyan.com 2019-11-21T09:48:23+00:00 urn:sha1:cc80695f6f17f922ce91f18804b44af89ed21f27 This attribute is always set to zero. 2019-11-14T23:23:15+00:00 Reid Kleckner rnk@google.com 2019-11-14T23:15:48+00:00 urn:sha1:4c1a1d3cf97e1ede466e2ad318f2811283ca0fb1 These are a pre-requisite to removing #include "llvm/Support/Options.h" from LLVMContext.h: https://reviews.llvm.org/D70280 2019-11-14T12:14:31+00:00 Miloš Stojanović Milos.Stojanovic@rt-rk.com 2019-11-14T11:52:56+00:00 urn:sha1:4787c6e2f31ece229daae8af12070d516ff4b1b4 This was fixed in rL229595 but this comment was missed. Differential Revision: https://reviews.llvm.org/D70231