Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-29T20:50:16+00:00 2020-01-29T20:50:16+00:00 Lang Hames lhames@gmail.com 2020-01-22T04:12:10+00:00 urn:sha1:32056b4eb87258884074f7f635bccd40fc44852c This should fix the build failure at http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/32524 and others. (cherry picked from commit e0a6093a744d16c90eafa62d7143ce41806b2466) 2020-01-29T20:50:16+00:00 Lang Hames lhames@gmail.com 2020-01-22T00:28:30+00:00 urn:sha1:32723d572077e9a3776553a2067563974e85e7c8 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) 2020-01-29T20:47:37+00:00 Lang Hames lhames@gmail.com 2020-01-17T22:48:48+00:00 urn:sha1:f7f0fd4a21d52d30f9b3257cd537fbc706f0f176 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) 2020-01-11T21:34:52+00:00 Fangrui Song maskray@google.com 2020-01-11T20:36:13+00:00 urn:sha1:6fdd6a7b3f696972edc244488f59532d05136a27 The argument is llvm::null() everywhere except llvm::errs() in llvm-objdump in -DLLVM_ENABLE_ASSERTIONS=On builds. It is used by no target but X86 in -DLLVM_ENABLE_ASSERTIONS=On builds. If we ever have the needs to add verbose log to disassemblers, we can record log with a member function, instead of passing it around as an argument. 2020-01-11T21:03:38+00:00 Lang Hames lhames@gmail.com 2020-01-11T20:58:38+00:00 urn:sha1:2cdb18afda841392002feafda21af31854c195b3 This fixes an off-by-one error in the argc value computed by runAsMain, and switches lli back to using the input bitcode (rather than the string "lli") as the effective program name. Thanks to Stefan Graenitz for spotting the bug. 2020-01-11T18:49:59+00:00 Lang Hames lhames@gmail.com 2020-01-11T17:59:33+00:00 urn:sha1:d2751f8fdf6c072045bab62f6035511e028f46ee Patch by Nicolas Capens. Thanks Nicolas! https://reviews.llvm.org/D65015 2020-01-03T20:54:03+00:00 Stefan Gränitz stefan.graenitz@gmail.com 2020-01-03T17:33:33+00:00 urn:sha1:c7191d3acddb997b093087e2be34c96ababbc427 2020-01-01T19:01:37+00:00 Mark de Wever koraq@xs4all.nl 2020-01-01T16:23:21+00:00 urn:sha1:8dc7b982b4556c243e0502e6e230bdd53ddd65ff This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71857 2019-12-25T01:12:21+00:00 Fangrui Song maskray@google.com 2019-12-25T01:10:32+00:00 urn:sha1:583ef13f0be7b0045f9508dfceee17ab4ef4b1ea 2019-12-21T05:10:49+00:00 Lang Hames lhames@gmail.com 2019-12-21T05:08:35+00:00 urn:sha1:9f4f237e29e7150dfcf04ae78fa287d2dc8d48e2 This matches the behavior of the legacy layer, which automatically deregistered frames.