summaryrefslogtreecommitdiffstats
path: root/llvm/include
Commit message (Collapse)AuthorAgeFilesLines
* Move RDF from Hexagon to CodegenScott Constable2020-06-243-0/+1359
| | | | | | | | RDF is designed to be target agnostic. Therefore it would be useful to have it available for other targets, such as X86. Based on a previous patch by Krzysztof Parzyszek Differential Revision: https://reviews.llvm.org/D75932
* [ManagedStatic] Fix build errors with clang-tblgen in Debug mode using MSVC ↵Denys Petrov2020-06-231-2/+2
| | | | | | | | | | | | | | | | | 2019 v16.6 After updating MSVS19 from v16.4 to v16.6 I faced with a build errors compiling in Debug mode. It complains on clang-tblgen.exe and llvm-tblgen.exe cmd line args. VS compiler had a bug. It dynamically creates an object with constexpr ctor in Debug mode. This bug was fixed in VS2019 v16.5. A workaround was implemented for that and everything works until v16.5 comes. The workaround became irrelevant since v16.5 and caused build errors. So I disabled the workaround for VS2019 v16.5 and higher. This relates to http://llvm.org/PR41367. Differential Revision: https://reviews.llvm.org/D80433 (cherry picked from commit 46e5c5fe778b92b2a7e2c2ad3610e1da6794bd5e)
* [PowerPC] Add missing handling for half precisionTom Stellard2020-06-221-0/+9
| | | | | | | | | | | | The fix for PR39865 took care of some of the handling for half precision but it missed a number of issues that still exist. This patch fixes the remaining issues that cause crashes in the PPC back end. Fixes: https://bugs.llvm.org/show_bug.cgi?id=45776 Differential revision: https://reviews.llvm.org/D79283 (cherry picked from commit 1a493b0fa556a07c728862c3c3f70bfd8683bef0)
* [PowerPC] Add support for vmsumudmAhsan Saghir2020-06-221-0/+3
| | | | | | | | | This patch adds support for Vector Multiply-Sum Unsigned Doubleword Modulo instruction; vmsumudm. Differential Revision: https://reviews.llvm.org/D80294 (cherry picked from commit a28e9f1208608f8d18750bb88ca74722fb0bcce4)
* [AARch64] Add Marvell ThunderX3T110 supportWei Zhao2020-06-171-0/+4
| | | | | | | | | | | This is the first checkin to support Marvell ThunderX3T110. Initial definition of the micro-ops of the instructions in ThunderX3T110 is included. Differential Revision: https://reviews.llvm.org/D78129 (cherry picked from commit 382d3a85e2a9269569e7fb8caa487d7ef57900c6)
* Backport 4878aa36d4a [ValueLattice] Add new state for undef constants.Florian Hahn2020-05-181-60/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NOTE: I mostly put it on Phabricator to make it easy for other people to fetch & check if that fixes a bug. This patch backports 4878aa36d4a and required earlier patches onto the release/10.x branch. It includes the following patches: aa5ebfdf205de6d599c1fed3161da3b63b6f0bef [ValueLattice] Make mark* functions public, return if value changed. c1943b42c5b7feff5d0e0c1358d02889e2be165f [ValueLattice] Update markConstantRange to return false equal ranges. e30c257811f62fea21704caa961c61e4559de202 [CVP,SCCP] Precommit test for D75055. 4878aa36d4aa27df644430139fab2734fde4a000 [ValueLattice] Add new state for undef constants. All patches except the last one apply cleanly. For the last one, the changes to SCCP.cpp were stripped, because SCCP does not yet use ValueLattice on release/10.x. Otherwise we would have to pull in more additional changes. Subscribers: tstellar, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76596
* Revert "Re-land [MC] Fix quadratic behavior in addPendingLabel"Tom Stellard2020-04-291-2/+1
| | | | | | | This reverts commit aa97472d211df67e91e8c1dd3188a0fb2ff942c8. This commit broke ABI compatibility: https://github.com/llvm/llvm-project/runs/624609989
* Re-land [MC] Fix quadratic behavior in addPendingLabelAlexandre Ganea2020-04-271-1/+2
| | | | | | | | This was discovered when compiling large unity/blob/jumbo files. Differential Revision: https://reviews.llvm.org/D78775 (cherry picked from commit fd773e8a51b82775f411061117173a21b500642a)
* [CodeView] Align type records on 4-bytes when emitting PDBsAlexandre Ganea2020-04-161-0/+5
| | | | | | | | | | | | | | | When emitting PDBs, the TypeStreamMerger class is used to merge .debug$T records from the input .OBJ files into the output .PDB stream. Records in .OBJs are not required to be aligned on 4-bytes, and "The Netwide Assembler 2.14" generates non-aligned records. When compiling with -DLLVM_ENABLE_ASSERTIONS=ON, an assert was triggered in MergingTypeTableBuilder when non-ghash merging was used. With ghash merging there was no assert. As a result, LLD could potentially generate a non-aligned TPI stream. We now align records on 4-bytes when record indices are remapped, in TypeStreamMerger::remapIndices(). Differential Revision: https://reviews.llvm.org/D75081 (cherry picked from commit a7325298e1f311b383b8ce5ba8e2d3698fef472a)
* [Clang][Driver] In -fintegrated-cc1 mode, avoid crashing on exit after a ↵Alexandre Ganea2020-03-132-0/+11
| | | | | | | | | | | | compiler crash After a crash catched by the CrashRecoveryContext, this patch prevents from accessing dangling pointers in TimerGroup structures before the clang tool exits. Previously, the default TimerGroup had internal linked lists which were still pointing to old Timer or TimerGroup instances, which lived in stack frames released by the CrashRecoveryContext. Fixes PR45164. Differential Revision: https://reviews.llvm.org/D76099 (cherry picked from commit 28ad9fc20823678881baa0d723834b88ea9e8e3a)
* Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)Hans Wennborg2020-03-031-0/+6
| | | | | | | | | | | | | and follow-ups: a2ca1c2d "build: disable zlib by default on Windows" 2181bf40 "[CMake] Link against ZLIB::ZLIB" 1079c68a "Attempt to fix ZLIB CMake logic on Windows" This changed the output of llvm-config --system-libs, and more importantly it broke stand-alone builds. Instead of piling on more fix attempts, let's revert this to reduce the risk of more breakages. (cherry picked from commit 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e)
* [llvm][Support][modulemap] Exclude WindowsSupport.h from the LLVM_Util moduleMichael Spencer2020-03-021-0/+3
| | | | | | | | | | | | | | rG01f9abbb50b1 moved WindowsSupport.h to include/llvm/Support/Windows/ This is a problem because the modulemap include all of the Support and ADT directories, thus any use of any header in Support or ADT would cause the compiler to try to build WindowsSupport.h, which only works on Windows. Fix this by explicitly excluding WindowsSupport.h from the LLVM_Util module. (cherry picked from commit 0b6abe428164c38c7dec6c539e454cfd671067a4)
* llvm-ar: Fix MinGW compilationHans Wennborg2020-02-281-0/+243
| | | | | | | | | | | | | | | | llvm-ar is using CompareStringOrdinal which is available only starting with Windows Vista (WINVER 0x600). Fix this by hoising WindowsSupport.h, which sets _WIN32_WINNT to 0x0601, up to llvm/include/llvm/Support and use it in llvm-ar. Patch by Cristian Adam! Differential revision: https://reviews.llvm.org/D74599 (cherry picked from commit 01f9abbb50b11dd26b9ccb7cb565cc955d2b9c74) This is for https://bugs.llvm.org/show_bug.cgi?id=44907
* [MC][ARM] Resolve some pcrel fixups at assembly time (PR44929)Hans Wennborg2020-02-271-1/+6
| | | | | | | | | | | | MC currently does not emit these relocation types, and lld does not handle them. Add FKF_Constant as a work-around of some ARM code after D72197. Eventually we probably should implement these relocation types. By Fangrui Song! Differential revision: https://reviews.llvm.org/D72892 (cherry picked from commit 2e24219d3cbfcb8c824c58872f97de0a2e94a7c8)
* [Clang][Driver] After default -fintegrated-cc1, make ↵Alexandre Ganea2020-02-122-0/+11
| | | | | | | | | | | | | llvm::report_fatal_error() generate preprocessed source + reproducer.sh again. Added a test for #pragma clang __debug llvm_fatal_error to test for the original issue. Added llvm::sys::Process::Exit() and replaced ::exit() in places where it was appropriate. This new function would call the current CrashRecoveryContext if one is running on the same thread; or call ::exit() otherwise. Fixes PR44705. Differential Revision: https://reviews.llvm.org/D73742 (cherry picked from commit faace365088a2a3a4cb1050a9facfc34a7a56577)
* [Clang] Remove unused #pragma clang __debug handle_crashAlexandre Ganea2020-02-101-4/+0
| | | | | | | | | As discussed in D70568, remove this because it isn't used anywhere, and I think it's better to go through real crashes for testing (#pragma clang __debug crash). Also remove the support function llvm::CrashRecoveryContext::HandleCrash() which was added at the same time by @ddunbar. Differential Revision: https://reviews.llvm.org/D74063 (cherry picked from commit 8ecde3ac34bbb5a8d53d8ec5cd32867658646df1)
* StringRef.h: __builtin_strlen seems to exist in VS 2017 MSVC 19.16 or laterHans Wennborg2020-02-071-1/+1
| | | | | | | This is a follow-up to ff837aa63cd, as discussed on the llvm-commits thread for that one. (cherry picked from commit 1b3d1661bbeb2c90f8f3ef6e2b77a70bc148731e)
* Actually, don't try to use __builtin_strlen in StringRef.h before VS 2019Hans Wennborg2020-02-031-2/+3
| | | | | | | | | The fix in b3d7d1061dc375bb5ea725e6597382fcd37f41d6 compiled nicely, but didn't link because at least the VS 2017 version I use doesn't have the builtin yet. Instead, make use of the builtin with MSVC conditional on VS 2019 or later. (cherry picked from commit ff837aa63cdfadb58f387ca77785ca3ca51c6976)
* Declare __builtin_strlen in StringRef.h as constexprHans Wennborg2020-02-031-1/+1
| | | | | | | | | | Otherwise Visual Studio 2017 will complain about llvm::StringRef::strlen not being constexpr: StringRef.h(80): error C3615: constexpr function 'llvm::StringRef::strLen' cannot result in a constant expression StringRef.h(84): note: failure was caused by call of undefined function or one not declared 'constexpr' (cherry picked from commit b3d7d1061dc375bb5ea725e6597382fcd37f41d6)
* [AArch64] -fpatchable-function-entry=N,0: place patch label after BTIFangrui Song2020-02-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For -fpatchable-function-entry=N,0 -mbranch-protection=bti, after 9a24488cb67a90f889529987275c5e411ce01dda, we place the NOP sled after the initial BTI. ``` .Lfunc_begin0: bti c nop nop .section __patchable_function_entries,"awo",@progbits,f,unique,0 .p2align 3 .xword .Lfunc_begin0 ``` This patch adds a label after the initial BTI and changes the __patchable_function_entries entry to reference the label: ``` .Lfunc_begin0: bti c .Lpatch0: nop nop .section __patchable_function_entries,"awo",@progbits,f,unique,0 .p2align 3 .xword .Lpatch0 ``` This placement is compatible with the resolution in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424 . A local linkage function whose address is not taken does not need a BTI. Placing the patch label after BTI has the advantage that code does not need to differentiate whether the function has an initial BTI. Reviewers: mrutland, nickdesaulniers, nsz, ostannard Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73680 (cherry picked from commit 06b8e32d4fd3f634f793e3bc0bc4fdb885e7a3ac)
* [ORC] Add support for emulated TLS to ORCv2.Lang Hames2020-01-295-52/+93
| | | | | | | | | | | | | | | | | | | | | | | This commit adds a ManglingOptions struct to IRMaterializationUnit, and replaces IRCompileLayer::CompileFunction with a new IRCompileLayer::IRCompiler class. The ManglingOptions struct defines the emulated-TLS state (via a bool member, EmulatedTLS, which is true if emulated-TLS is enabled and false otherwise). The IRCompileLayer::IRCompiler class wraps an IRCompiler (the same way that the CompileFunction typedef used to), but adds a method to return the IRCompileLayer::ManglingOptions that the compiler will use. These changes allow us to correctly determine the symbols that will be produced when a thread local global variable defined at the IR level is compiled with or without emulated TLS. This is required for ORCv2, where MaterializationUnits must declare their interface up-front. Most ORCv2 clients should not require any changes. Clients writing custom IR compilers will need to wrap their compiler in an IRCompileLayer::IRCompiler, rather than an IRCompileLayer::CompileFunction, however this should be a straightforward change (see modifications to CompileUtils.* in this patch for an example). (cherry picked from commit ce2207abaf9a925b35f15ef92aaff6b301ba6d22)
* [ORC] Add weak symbol support to defineMaterializing, fix for PR40074.Lang Hames2020-01-291-4/+9
| | | | | | | | | | | | | | | | | | The MaterializationResponsibility::defineMaterializing method allows clients to add new definitions that are in the process of being materialized to the JIT. This patch adds support to defineMaterializing for symbols with weak linkage where the new definitions may be rejected if another materializer concurrently defines the same symbol. If a weak symbol is rejected it will not be added to the MaterializationResponsibility's responsibility set. Clients can check for membership in the responsibility set via the MaterializationResponsibility::getSymbols() method before resolving any such weak symbols. This patch also adds code to RTDyldObjectLinkingLayer to tag COFF comdat symbols introduced during codegen as weak, on the assumption that these are COFF comdat constants. This fixes http://llvm.org/PR40074. (cherry picked from commit 84217ad66115cc31b184374a03c8333e4578996f)
* [PassManagerBuilder] Remove global extension when a plugin is unloadedElia Geretto2020-01-291-3/+25
| | | | | | | | | | | | This commit fixes PR39321. GlobalExtensions is not guaranteed to be destroyed when optimizer plugins are unloaded. If it is indeed destroyed after a plugin is dlclose-d, the destructor of the corresponding ExtensionFn is not mapped anymore, causing a call to unmapped memory during destruction. This commit guarantees that extensions coming from external plugins are removed from GlobalExtensions when the plugin is unloaded if GlobalExtensions has not been destroyed yet. Differential Revision: https://reviews.llvm.org/D71959 (cherry picked from commit ab2300bc154f7bed43f85f74fd3fe31be71d90e0)
* Add function attribute "patchable-function-prefix" to support ↵Fangrui Song2020-01-241-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -fpatchable-function-entry=N,M where M>0 Similar to the function attribute `prefix` (prefix data), "patchable-function-prefix" inserts data (M NOPs) before the function entry label. -fpatchable-function-entry=2,1 (1 NOP before entry, 1 NOP after entry) will look like: ``` .type foo,@function .Ltmp0: # @foo nop foo: .Lfunc_begin0: # optional `bti c` (AArch64 Branch Target Identification) or # `endbr64` (Intel Indirect Branch Tracking) nop .section __patchable_function_entries,"awo",@progbits,get,unique,0 .p2align 3 .quad .Ltmp0 ``` -fpatchable-function-entry=N,0 + -mbranch-protection=bti/-fcf-protection=branch has two reasonable placements (https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01185.html): ``` (a) (b) func: func: .Ltmp0: bti c bti c .Ltmp0: nop nop ``` (a) needs no additional code. If the consensus is to go for (b), we will need more code in AArch64BranchTargets.cpp / X86IndirectBranchTracking.cpp . Differential Revision: https://reviews.llvm.org/D73070 (cherry picked from commit 22467e259507f5ead2a87d989251b4c951a587e4)
* [XRay] Set hasSideEffects flag of PATCHABLE_FUNCTION_{ENTER,EXIT}Fangrui Song2020-01-241-2/+2
| | | | | | Otherwise they may be picked as the delay slot by mips-delay-slot-filler, if we move patchable-function before mips-delay-slot-filler. (cherry picked from commit a72d15e37c5e066f597f13a8ba60aff214ac992d)
* [ELF][PowerPC] Support R_PPC_COPY and R_PPC64_COPYFangrui Song2020-01-241-0/+2
| | | | | | | | Reviewed By: Bdragon28, jhenderson, grimar, sfertile Differential Revision: https://reviews.llvm.org/D73255 (cherry picked from commit f1dab29908d25a4044abff6ffc120c48b20f034d)
* [RISCV] Fix evaluating %pcrel_lo against global and weak symbolsJames Clarke2020-01-232-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we would erroneously turn %pcrel_lo(label), where label has a %pcrel_hi against a weak symbol, into %pcrel_lo(label + offset), as evaluatePCRelLo would believe the target independent logic was going to fold it. Moreover, even if that were fixed, shouldForceRelocation lacks an MCAsmLayout and thus cannot evaluate the %pcrel_hi fixup to a value and check the symbol, so we would then erroneously constant-fold the %pcrel_lo whilst leaving the %pcrel_hi intact. After D72197, this same sequence also occurs for symbols with global binding, which is triggered in real-world code. Instead, as discussed in D71978, we introduce a new FKF_IsTarget flag to avoid these kinds of issues. All the resolution logic happens in one place, with no coordination required between RISCAsmBackend and RISCVMCExpr to ensure they implement the same logic twice. Although the implementation of %pcrel_hi can be left as target independent, we make it target dependent to ensure that they are handled identically to %pcrel_lo, otherwise we risk one of them being constant folded but the other being preserved. This also allows us to properly support fixup pairs where the instructions are in different fragments. Reviewers: asb, lenary, efriedma Reviewed By: efriedma Subscribers: arichardson, hiraditya, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73211 (cherry picked from commit 3f5976c97dbfefb4669abcf968bd79a9a64c18e0)
* [Transforms][RISCV] Remove a "using namespace llvm" from an include file. ↵Craig Topper2020-01-171-9/+7
| | | | | | | | | | | | Fix a place that became dependent on it. This include file was created in October and has a "using namespace llvm". This seems to get exposed to other include files and finally onto cpp files. While this somewhat okay for llvm itself, its bad for other projects that use llvm as a library and includes a header file that picks this up. This was found by ISPC which has some class names at gloal scope with the same names as LLVM. It looks like RISCV accidentally became dependent on this. I fixed it by reordering some includes in the RISCV code, but maybe we want to change the TableGenEmitter to put "namespace llvm {" in the generated file instead? But we probably want to do the simplest thing first so we can merge it to 10.0. Differential Revision: https://reviews.llvm.org/D72895 (cherry picked from commit caee96031d3be9f951e4a17c8d3fb1c8b748fb31)
* [yaml2obj/obj2yaml] - Add support for SHT_RELR sections.Georgii Rymar2020-01-151-0/+12
| | | | | | | | | | | | | | | | | | | Note: this is a reland with a trivial 2 lines fix in ELFState<ELFT>::writeSectionContent. It adds a check similar to ones we already have for other sections to fix the case revealed by bots, like http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/60744. The encoded sequence of Elf*_Relr entries in a SHT_RELR section looks like [ AAAAAAAA BBBBBBB1 BBBBBBB1 ... AAAAAAAA BBBBBB1 ... ] i.e. start with an address, followed by any number of bitmaps. The address entry encodes 1 relocation. The subsequent bitmap entries encode up to 63(31) relocations each, at subsequent offsets following the last address entry. More information is here: https://github.com/llvm-mirror/llvm/blob/master/lib/Object/ELF.cpp#L272 This patch adds a support for these sections. Differential revision: https://reviews.llvm.org/D71872
* Revert "[yaml2obj/obj2yaml] - Add support for SHT_RELR sections."Georgii Rymar2020-01-151-12/+0
| | | | | | This reverts commit 46d11e30ee807accefd14e0b7f306647963a39b5. It broke bots. E.g. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/60744
* [Support] Replace Windows __declspec(thread) with thread_local for ↵Russell Gallop2020-01-151-11/+7
| | | | | | | | | | | | | LLVM_THREAD_LOCAL Windows minimum host tools version is now VS2017, which supports C++11 thread_local so use this for LLVM_THREAD_LOCAL instead of declspec(thread). According to [1], thread_local is implemented with declspec(thread) so this should be NFC. [1] https://docs.microsoft.com/en-us/cpp/cpp/thread?view=vs-2017 Differential Revision: https://reviews.llvm.org/D72399
* [AArch64][SVE] Add ptest intrinsicsCullen Rhodes2020-01-151-0/+14
| | | | | | | | | | | | | | | | | | | Summary: Implements the following intrinsics: * @llvm.aarch64.sve.ptest.any * @llvm.aarch64.sve.ptest.first * @llvm.aarch64.sve.ptest.last Reviewers: sdesmalen, efriedma, dancgr, mgudim, cameron.mcinally, rengolin Reviewed By: efriedma Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72398
* [yaml2obj/obj2yaml] - Add support for SHT_RELR sections.Georgii Rymar2020-01-151-0/+12
| | | | | | | | | | | | | | | The encoded sequence of Elf*_Relr entries in a SHT_RELR section looks like [ AAAAAAAA BBBBBBB1 BBBBBBB1 ... AAAAAAAA BBBBBB1 ... ] i.e. start with an address, followed by any number of bitmaps. The address entry encodes 1 relocation. The subsequent bitmap entries encode up to 63(31) relocations each, at subsequent offsets following the last address entry. More information is here: https://github.com/llvm-mirror/llvm/blob/master/lib/Object/ELF.cpp#L272 This patch adds a support for these sections. Differential revision: https://reviews.llvm.org/D71872
* [DWARF] Fix DWARFDebugAranges to support 64-bit CU offsets.Igor Kudrin2020-01-151-4/+4
| | | | | | DWARFContext, the only user of this class, can already handle such offsets. Differential Revision: https://reviews.llvm.org/D71834
* [Attributor] AAValueConstantRange: Value range analysis using constant rangeHideto Ueno2020-01-151-0/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
* [Scheduler] Adjust interface of CreateTargetMIHazardRecognizer to use ↵David Green2020-01-151-1/+2
| | | | | | | | ScheduleDAGMI. NFC All the callers of this function will be ScheduleDAGMI from the MachineScheduler. This allows us to use the extra info available in ScheduleDAGMI without resorting to awkward casts.
* CMake: Make most target symbols hidden by defaultTom Stellard2020-01-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [GVN] fix comment/argument name to match actual implementation. NFCFedor Sergeev2020-01-151-2/+2
|
* [NewPM] Port MergeFunctions passNikita Popov2020-01-142-1/+33
| | | | | | | | | | This ports the MergeFunctions pass to the NewPM. This was rather straightforward, as no analyses are used. Additionally MergeFunctions needs to be conditionally enabled in the PassBuilder, but I left that part out of this patch. Differential Revision: https://reviews.llvm.org/D72537
* [ThinLTO] Handle variable with twice promoted name (Rust)Teresa Johnson2020-01-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Ensure that we can internalize values produced from two rounds of promotion. Note that this cannot happen currently via clang, but in other use cases such as the Rust compiler which does a first round of ThinLTO on library code, producing bitcode, and a second round on the final binary. In particular this can happen if a function is exported and promoted, ending up with a ".llvm.${hash}" suffix, and then goes through a round of optimization creating an internal switch table expansion variable that is internal and contains the promoted name of the enclosing function. This variable will be promoted in the second round of ThinLTO if @foo is imported again, and therefore ends up with two ".llvm.${hash}" suffixes. Only the final one should be stripped when consulting the index to locate the summary. Reviewers: wmi Subscribers: mehdi_amini, inglorion, hiraditya, JDevlieghere, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72711
* SCC: Allow ReplaceNode to safely support insertionWarren Ristow2020-01-141-1/+4
| | | | | | | | | | | If scc_iterator::ReplaceNode is inserting a new entry in the map, rather than replacing an existing entry, the possibility of growing the map could cause a failure. This change safely implements the insertion. Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D72469
* Removed PointerUnion3 and PointerUnion4 aliases in favor of the variadic ↵Dmitri Gribenko2020-01-142-14/+4
| | | | template
* [FPEnv] Add some comments to IRBuilder.hUlrich Weigand2020-01-141-0/+6
| | | | | As requested via post-commit comment for D71467, this adds comments documenting CreateFCmp vs. CreateFCmpS to the header file.
* [RISCV][NFC] Deduplicate Atomic Intrinsic DefinitionsSam Elliott2020-01-141-45/+45
| | | | | | | | | | | | | | | | | Summary: This is a slight cleanup, to use multiclasses to avoid the duplication between the different atomic intrinsic definitions. The produced intrinsics are unchanged, they're just generated in a more succinct way. Reviewers: asb, luismarques, jrtc27 Reviewed By: luismarques, jrtc27 Subscribers: Jim, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, jfb, PkmX, jocewei, psnobl, benna, s.egerton, pzheng, sameer.abuasal, apazos, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71777
* [Target] Fix uninitialized value in 10c11e4e2d05cf0e8f8251f50d84ce77eb1e9b8dSam McCall2020-01-141-1/+1
|
* [GlobalISel] Change representation of shuffle masks in MachineOperand.Eli Friedman2020-01-133-6/+9
| | | | | | | | | | | | We're planning to remove the shufflemask operand from ShuffleVectorInst (D72467); fix GlobalISel so it doesn't depend on that Constant. The change to prelegalizercombiner-shuffle-vector.mir happens because the input contains a literal "-1" in the mask (so the parser/verifier weren't really handling it properly). We now treat it as equivalent to "undef" in all contexts. Differential Revision: https://reviews.llvm.org/D72663
* [Dsymutil][Debuginfo][NFC] #3 Refactor dsymutil to separate DWARF optimizing ↵Alexey Lapshin2020-01-131-0/+112
| | | | | | | | | | | | | | | | | | | | | | | | part. Summary: This is the next portion of patches for dsymutil. Create DwarfEmitter interface to generate all debug info tables. Put DwarfEmitter into DwarfLinker library and make tools/dsymutil/DwarfStreamer to be child of DwarfEmitter. It passes check-all testing. MD5 checksum for clang .dSYM bundle matches for the dsymutil with/without that patch. Reviewers: JDevlieghere, friss, dblaikie, aprantl Reviewed By: JDevlieghere Subscribers: merge_guards_bot, hiraditya, thegameg, probinson, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D72476
* [LTO] Constify lto::Config reference passed to backends (NFC)Teresa Johnson2020-01-132-5/+6
| | | | | | | | The lto::Config object saved on the global LTO object should not be updated by any of the LTO backends. Otherwise we could run into interference between threads utilizing it. Motivated by some proposed changes that would have caused it to get modified in the ThinLTO backends.
* Rework be15dfa88fb1 such that it works with GlobalISel which doesn't use EVTDaniel Sanders2020-01-131-0/+10
| | | | | | | | | | | | | | | | | | | | | Summary: be15dfa88fb1 broke GlobalISel's usage of getSetCCInverse() which currently appears to be limited to our out-of-tree backend. GlobalISel doesn't use EVT's and isn't able to derive them from the information it has as it doesn't distinguish between integer and floating point types (that distinction is made by operations rather than values). Bring back the bool version of getSetCCInverse() in a way that doesn't break the intent of be15dfa88fb1 but also allows GlobalISel to continue using it. Reviewers: spatel, bogner, arichardson Reviewed By: arichardson Subscribers: rovka, hiraditya, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72309
* GlobalISel: Fix assertion on wide G_ZEXT sourcesMatt Arsenault2020-01-131-1/+2
| | | | It's possible to have a type that needs a mask greater than 64-bits.
OpenPOWER on IntegriCloud