summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Remove Fuchsia-specific knowledge to pick the ABI versionLouis Dionne2018-09-262-12/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: The ABI version used by libc++ is a configuration option just like any other configuration option. It is a knob that can be used by vendors to customize the libc++ that they ship. As such, we should not be hardcoding vendor-specific configuration choices in libc++. When building libc++ for Fuchsia, Fuchsia's build scripts should simply define the libc++ ABI version to 2 -- this will result in the _LIBCPP_ABI_VERSION macro being defined in the __config header that is generated when libc++ is built and installed, which is the correct way to customize libc++'s behavior for specific vendors. Reviewers: phosek, EricWF Subscribers: mgorny, christof, dexonsmith, cfe-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D52397 llvm-svn: 343079
* [ELF] - Do not fail on R_*_NONE relocations when parsing the debug info.George Rimar2018-09-2616-2/+81
| | | | | | | | | | | | | | | | | This is https://bugs.llvm.org//show_bug.cgi?id=38919. Currently, LLD may report "unsupported relocation target while parsing debug info" when parsing the debug information. At the same time LLD does that for zeroed R_X86_64_NONE relocations, which obviously has "invalid" targets. The nature of R_*_NONE relocation assumes them should be ignored. This patch teaches LLD to stop reporting the debug information parsing errors for them. Differential revision: https://reviews.llvm.org/D52408 llvm-svn: 343078
* [clang-cl] Make /Gs imply default stack probes, not /Gs0 (PR39074)Hans Wennborg2018-09-262-5/+5
| | | | | | Differential revision: https://reviews.llvm.org/D52499 llvm-svn: 343077
* Fix a memory read bug in lldb-serverPavel Labath2018-09-262-7/+85
| | | | | | | | | | | | | | NativeProcessProtocol::ReadMemoryWithoutTrap had a bug, where it failed to properly remove inserted breakpoint opcodes if the memory read partially overlapped the trap opcode. This could not happen on x86 because it has a one-byte breakpoint instruction, but it could happen on arm, which has a 4-byte breakpoint instruction (in arm mode). Since triggerring this condition would only be possible on an arm machine (and even then it would be a bit tricky). I test this using a NativeProcessProtocol unit test. llvm-svn: 343076
* [CUDA] Fix two failed test cases using --cuda-path-ignore-envJiading Gai2018-09-262-3/+3
| | | | | | | | | | | Add --cuda-path-ignore-env option to those test cases to ensure the clang driver always pick the CUDA path specified by --sysroot. Reviewers: tra, Hahnfeld Differential Revision: https://reviews.llvm.org/D52259 llvm-svn: 343075
* [CMake] [MinGW] Build address sanitizer for MinGW if building with clangMartin Storsjo2018-09-263-2/+20
| | | | | | Differential Revision: https://reviews.llvm.org/D51885 llvm-svn: 343074
* [ASan] [MinGW] Only try to export MSVC specific C++ symbols if building with ↵Martin Storsjo2018-09-261-1/+1
| | | | | | | | a MSVC like compiler Differential Revision: https://reviews.llvm.org/D51878 llvm-svn: 343073
* [Frontend] Tidy up -print-decl-contexts conditionsFangrui Song2018-09-261-64/+41
| | | | | | | The existing conditions are not consistent. Some have braces and define a temporary Decl while others simply call `<< *cast<XXXDecl>(I)` (mostly the NamedDecl overload of operator<<). Just use the latter for consistency and brevity. llvm-svn: 343072
* Silence compiler warning about unused variable introduced in r343018Mikael Holmen2018-09-261-1/+1
| | | | | | | | | Since the body of the "else if" contains // TODO I suppose someone will need the variable again at some point, but with -Werror the warning made it not compile at all. llvm-svn: 343071
* [COFF] Don't do autoexport of symbols from GNU import librariesMartin Storsjo2018-09-263-5/+51
| | | | | | | | | | This involves adding more generic list of symbol suffixes/prefixes to ignore for autoexport; adding a few other entries to these lists as well from the corresponding lists in binutils. Differential Revision: https://reviews.llvm.org/D52382 llvm-svn: 343070
* [COFF] Allow automatic dllimport from gnu import librariesMartin Storsjo2018-09-265-12/+73
| | | | | | | | | Don't assume that the IAT chunk will be a DefinedImportData, it can just as well be a DefinedRegular for gnu import libraries. Differential Revision: https://reviews.llvm.org/D52381 llvm-svn: 343069
* [ORC] Remove a superfluous semicolon, fixing warnings. NFC.Martin Storsjo2018-09-261-1/+1
| | | | llvm-svn: 343068
* [clangd] Fix crash if pending computations were active on exitIlya Biryukov2018-09-262-62/+69
| | | | | | | | | | | | | | | | Summary: Make sure JSONRPCDispatcher outlives the worker threads, they access its fields to remove the stored cancellations when Context dies. Reviewers: sammccall, ioeric Reviewed By: ioeric Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52420 llvm-svn: 343067
* [clangd] Handle template args for disabled function arg snippetsIlya Biryukov2018-09-262-15/+78
| | | | | | | | | | | | Reviewers: kadircet, ioeric, sammccall Reviewed By: kadircet Subscribers: MaskRay, jkorous, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D52422 llvm-svn: 343066
* [ORC] Update CompileOnDemandLayer2 to use the new lazyReexports mechanismLang Hames2018-09-267-93/+82
| | | | | | | | | | | | for lazy compilation, rather than a callback manager. The new mechanism does not block compile threads, and does not require function bodies to be renamed. Future modifications should allow laziness on a per-module basis to work without any modification of the input module. llvm-svn: 343065
* P0859R0: List-initialization is potentially-constant-evaluated andRichard Smith2018-09-264-10/+84
| | | | | | | | | | | | triggers instantiation of constexpr functions. We mostly implemented this since Clang 6, but missed the template instantiation case. We do not implement the '&cast-expression' special case. It appears to be a mistake / oversight. I've mailed CWG to see if we can remove it. llvm-svn: 343064
* [OPENMP] Add support for OMP5 requires directive + unified_address clauseKelvin Li2018-09-2635-3/+483
| | | | | | | | | Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
* [DebugInfo] Do not generate address info for removed debug labels.Hsiangkai Wang2018-09-262-4/+42
| | | | | | | | | | | | | | | In some senario, LLVM will remove llvm.dbg.labels in IR. For example, when the labels are in unreachable blocks, these labels will not be generated in LLVM IR. In the case, these debug labels will have address zero as their address. It is not legal address for debugger to set breakpoints or query sources. So, the patch inhibits the address info (DW_AT_low_pc) of removed labels. Fix build failed in BuildBot, clang-stage1-cmake-RA-incremental, on macOS. Differential Revision: https://reviews.llvm.org/D51908 llvm-svn: 343062
* [ORC] Add a "lazy call-through" utility based on the same underlying trampolineLang Hames2018-09-267-38/+510
| | | | | | | | | | | | | | | | | | | | implementation as lazy compile callbacks, and a "lazy re-exports" utility that builds lazy call-throughs. Lazy call-throughs are similar to lazy compile callbacks (and are based on the same underlying state saving/restoring trampolines) but resolve their targets by performing a standard ORC lookup rather than invoking a user supplied compiler callback. This allows them to inherit the thread-safety of ORC lookups while blocking only the calling thread (whereas compile callbacks also block one compile thread). Lazy re-exports provide a simple way of building lazy call-throughs. Unlike a regular re-export, a lazy re-export generates a new address (a stub entry point) that will act like the re-exported symbol when called. The first call via a lazy re-export will trigger compilation of the re-exported symbol before calling through to it. llvm-svn: 343061
* [ORC] Fix BuildingAJIT tutorial examples that were broken by r343059.Lang Hames2018-09-262-4/+4
| | | | | | | createLocalCompileCallbackManager now returns an Expected value. This commit wraps the call with cantFail to unwrap it. llvm-svn: 343060
* [ORC] Refactor trampoline pool management out of JITCompileCallbackManager.Lang Hames2018-09-266-128/+285
| | | | | | | | | | | | | | | | | This will allow trampoline pools to be re-used for a new lazy-reexport utility that generates looks up function bodies using the standard symbol lookup process (rather than using a user provided compile function). This new utility provides the same capabilities (since MaterializationUnits already allow user supplied compile functions to be run) as JITCompileCallbackManager, but can use the new asynchronous lookup functions to avoid blocking a compile thread. This patch also updates createLocalCompileCallbackManager to return an error if a callback manager can not be created, and updates clients of that API to account for the change. Finally, the OrcCBindingsStack is updates so that if a callback manager is not available for the target platform a valid stack (without support for lazy compilation) can still be constructed. llvm-svn: 343059
* [ORC] Add support for multithreaded compiles to LLJIT and LLLazyJIT.Lang Hames2018-09-265-19/+183
| | | | | | | | | | | | | | | | | | | LLJIT and LLLazyJIT can now be constructed with an optional NumCompileThreads arguments. If this is non-zero then a thread-pool will be created with the given number of threads, and compile tasks will be dispatched to the thread pool. To enable testing of this feature, two new flags are added to lli: (1) -compile-threads=N (N = 0 by default) controls the number of compile threads to use. (2) -thread-entry can be used to execute code on additional threads. For each -thread-entry argument supplied (multiple are allowed) a new thread will be created and the given symbol called. These additional thread entry points are called after static constructors are run, but before main. llvm-svn: 343058
* [ORC] Include-what-you-use fixes.Lang Hames2018-09-261-0/+2
| | | | llvm-svn: 343057
* [ORC] Fix a missing include in r343055.Lang Hames2018-09-261-0/+2
| | | | llvm-svn: 343056
* [ORC] Add ThreadSafeModule and ThreadSafeContext wrappers to support concurrentLang Hames2018-09-2615-181/+364
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compilation of IR in the JIT. ThreadSafeContext is a pair of an LLVMContext and a mutex that can be used to lock that context when it needs to be accessed from multiple threads. ThreadSafeModule is a pair of a unique_ptr<Module> and a shared_ptr<ThreadSafeContext>. This allows the lifetime of a ThreadSafeContext to be managed automatically in terms of the ThreadSafeModules that refer to it: Once all modules using a ThreadSafeContext are destructed, and providing the client has not held on to a copy of shared context pointer, the context will be automatically destructed. This scheme is necessary due to the following constraits: (1) We need multiple contexts for multithreaded compilation (at least one per compile thread plus one to store any IR not currently being compiled, though one context per module is simpler). (2) We need to free contexts that are no longer being used so that the JIT does not leak memory over time. (3) Module lifetimes are not predictable (modules are compiled as needed depending on the flow of JIT'd code) so there is no single point where contexts could be reclaimed. JIT clients not using concurrency can safely use one ThreadSafeContext for all ThreadSafeModules. JIT clients who want to be able to compile concurrently should use a different ThreadSafeContext for each module, or call setCloneToNewContextOnEmit on their top-level IRLayer. The former reduces compile latency (since no clone step is needed) at the cost of additional memory overhead for uncompiled modules (as every uncompiled module will duplicate the LLVM types, constants and metadata that have been shared). llvm-svn: 343055
* Remove LoopID metadata from the branch instructionVyacheslav Zakharin2018-09-263-16/+62
| | | | | | | | that follows the peeled iterations. Differential Revision: https://reviews.llvm.org/D52176 llvm-svn: 343054
* Revert "Revert "[ConstHoist] Do not rebase single (or few) dependent constant""Zhaoshi Zheng2018-09-262-22/+237
| | | | | | | | | | | | | | | | | | | This reverts commit bd7b44f35ee9fbe365eb25ce55437ea793b39346. Reland r342994: disabled the optimization and explicitly enable it in test. -mllvm -consthoist-min-num-to-rebase<unsigned>=0 [ConstHoist] Do not rebase single (or few) dependent constant If an instance (InsertionPoint or IP) of Base constant A has only one or few rebased constants depending on it, do NOT rebase. One extra ADD instruction is required to materialize each rebased constant, assuming A and the rebased have the same materialization cost. Differential Revision: https://reviews.llvm.org/D52243 llvm-svn: 343053
* [WebAssembly] SIMD conversionsThomas Lively2018-09-263-0/+140
| | | | | | | | | | | | | | | | Summary: Lowers (s|u)itofp and fpto(s|u)i instructions for vectors. The fp to int conversions produce poison values if their arguments are out of the convertible range, so a future CL will have to add an LLVM intrinsic to make the saturating behavior of this conversion usable. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D52372 llvm-svn: 343052
* [analyzer] Fix a crash on casting symbolic pointers to derived classes.Artem Dergachev2018-09-262-1/+41
| | | | | | | | | | | Commit r340984 causes a crash when a pointer to a completely unrelated type UnrelatedT (eg., opaque struct pattern) is being casted from base class BaseT to derived class DerivedT, which results in an ill-formed region Derived{SymRegion{$<UnrelatedT x>}, DerivedT}. Differential Revision: https://reviews.llvm.org/D52189 llvm-svn: 343051
* Fix a bot failure from r343042.Erik Pilkington2018-09-251-2/+2
| | | | llvm-svn: 343050
* [DAGCombiner] Remove unnecessary check for visitSDIVLike/visitUDIVLike ↵Craig Topper2018-09-251-2/+1
| | | | | | | | returning a UDIVREM or SDIVREM node. This shouldn't be possible and is a leftover from when we used to recursively call combine here. llvm-svn: 343049
* [analyzer] Add a testing facility for testing relationships between symbols.Artem Dergachev2018-09-254-521/+708
| | | | | | | | | | | | | | | | | | Tests introduced in r329780 was disabled in r342317 because these tests were accidentally testing dump infrastructure, when all they cared about was how symbols relate to each other. So when dump infrastructure changed, tests became annoying to maintain. Add a new feature to ExprInspection: clang_analyzer_denote() and clang_analyzer_explain(). The former adds a notation to a symbol, the latter expresses another symbol in terms of previously denoted symbols. It's currently a bit wonky - doesn't print parentheses and only supports denoting atomic symbols. But it's even more readable that way. Differential Revision: https://reviews.llvm.org/D52133 llvm-svn: 343048
* [AMDGPU] Fix ds combine with subregsStanislav Mekhanoshin2018-09-252-17/+117
| | | | | | Differential Revision: https://reviews.llvm.org/D52522 llvm-svn: 343047
* [X86] Allow movmskpd/ps ISD nodes to be created and selected with integer ↵Craig Topper2018-09-254-76/+36
| | | | | | | | | | input types. This removes an int->fp bitcast between the surrounding code and the movmsk. I had already added a hack to combineMOVMSK to try to look through this bitcast to improve the SimplifyDemandedBits there. But I found an additional issue where the bitcast was preventing combineMOVMSK from being called again after earlier nodes in the DAG are optimized. The bitcast gets revisted, but not the user of the bitcast. By using integer types throughout, the bitcast doesn't get in the way. llvm-svn: 343046
* [X86] Add some more movmsk test cases. NFCCraig Topper2018-09-251-0/+232
| | | | | | | | These IR patterns represent the exact behavior of a movmsk instruction using (zext (bitcast (icmp slt X, 0))). For the v4i32/v8i32/v2i64/v4i64 we currently emit a PCMPGT for the icmp slt which is unnecessary since we only care about the sign bit of the result. This is because of the int->fp bitcast we put on the input to the movmsk nodes for these cases. I'll be fixing this in a future patch. llvm-svn: 343045
* [clang-check-codegen][cfstring] Accept either @ or % for progbits to make ↵Kristina Brooks2018-09-251-1/+1
| | | | | | | | | | | | | | | | | ppc64be bots happy. PPC64BE bots use % instead of @ for directives like progbits. Since CFString tests also check asm output, they fail on the following: cfstring3.c:44:19: error: CHECK-ASM-ELF: expected string not found in input // CHECK-ASM-ELF: .section cfstring,"aw",@progbits <stdin>:30:2: note: possible intended match here .section cfstring,"aw",%progbits Updating that check with a {{[@%]}}progbits regex to make those bots happy. llvm-svn: 343044
* [ORC] Add an asynchronous jit-link function, jitLinkForORC, to RuntimeDyld andLang Hames2018-09-255-60/+215
| | | | | | | | | | | | | | | | | switch RTDyldObjectLinkingLayer2 to use it. RuntimeDyld::loadObject is currently a blocking operation. This means that any JIT'd code whose call-graph contains an embedded complete K graph will require at least K threads to link, which precludes the use of a fixed sized thread pool for concurrent JITing of arbitrary code (whatever K the thread-pool is set at, any code with a K+1 complete subgraph will deadlock at JIT-link time). To address this issue, this commmit introduces a function called jitLinkForORC that uses continuation-passing style to pass the fix-up and finalization steps to the asynchronous symbol resolver interface so that linking can be performed without blocking. llvm-svn: 343043
* [Sema] Use a more civilized hash map to implement -Wduplicate-enum.Erik Pilkington2018-09-252-2/+10
| | | | | | | | | DenseMap<long, SOMETHING> used LONG_MAX as a tombstone, so it asserts when you try to insert it! rdar://44774672 llvm-svn: 343042
* [InstCombine] add fneg variation of shuffle-binop fold; NFCSanjay Patel2018-09-251-0/+11
| | | | | | | | If the fsub in this pattern was replaced by an actual fneg instruction, we would need to add a fold to recognize that because fneg would not be a binop. llvm-svn: 343041
* Don't emit "will be treated as an identifier character" warning forRichard Smith2018-09-252-4/+7
| | | | | | | UTF-8 characters that aren't identifier characters in the current language mode. llvm-svn: 343040
* [clangd] Remove unused using-declaration testing::AllOfFangrui Song2018-09-251-1/+0
| | | | llvm-svn: 343039
* Reland "[Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with ↵Kristina Brooks2018-09-254-41/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `-fconstant-cfstrings`" Relanding rL342883 with more fragmented tests to test ELF-specific section emission separately from broad-scope CFString tests. Now this tests the following separately 1). CoreFoundation builds and linkage for ELF while building it. 2). CFString ELF section emission outside CF in assembly output. 3). Broad scope `cfstring3.c` tests which cover all object formats at bitcode level and assembly level (including ELF). This fixes non-bridged CoreFoundation builds on ELF targets that use -fconstant-cfstrings. The original changes from differential for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not check for an edge case where the global could be a constant which surfaced as an issue when building for ELF because of different linkage semantics. This patch addresses several issues with crashes related to CF builds on ELF as well as improves data layout by ensuring string literals that back the actual CFConstStrings end up in .rodata in line with Mach-O. Change itself tested with CoreFoundation on Linux x86_64 but should be valid for BSD-like systems as well that use ELF as the native object format. Differential Revision: https://reviews.llvm.org/D52344 llvm-svn: 343038
* [analyzer] NFC: CallDescription: Improve array management.Artem Dergachev2018-09-252-24/+16
| | | | | | | | | | Combine the two constructor overrides into a single ArrayRef constructor to allow easier brace initializations and simplify how the respective field is used internally. Differential Revision: https://reviews.llvm.org/D51390 llvm-svn: 343037
* P0969R0: allow structured binding of accessible members, not only public ↵Richard Smith2018-09-257-54/+108
| | | | | | members. llvm-svn: 343036
* [analyzer] NFC: Legalize state manager factory injection.Artem Dergachev2018-09-255-83/+101
| | | | | | | | | | | | | | | | | | | | | When a checker maintains a program state trait that isn't a simple list/set/map, but is a combination of multiple lists/sets/maps (eg., a multimap - which may be implemented as a map from something to set of something), ProgramStateManager only contains the factory for the trait itself. All auxiliary lists/sets/maps need a factory to be provided by the checker, which is annoying. So far two checkers wanted a multimap, and both decided to trick the ProgramStateManager into keeping the auxiliary factory within itself by pretending that it's some sort of trait they're interested in, but then never using this trait but only using the factory. Make this trick legal. Define a convenient macro. One thing that becomes apparent once all pieces are put together is that these two checkers are in fact using the same factory, because the type that identifies it, ImmutableMap<const MemRegion *, ImmutableSet<SymbolRef>>, is the same. This situation is different from two checkers registering similar primitive traits. Differential Revision: https://reviews.llvm.org/D51388 llvm-svn: 343035
* [WebAssembly] Add --export-default/--no-export-default optionsSam Clegg2018-09-255-2/+26
| | | | | | | | | | | | | These option control weather or not symbols marked as visibility default are exported in the output binary. By default this is true, but emscripten prefers to control the exported symbol list explicitly at link time and ignore the symbol attributes. Differential Revision: https://reviews.llvm.org/D52003 llvm-svn: 343034
* [lldb-mi] Fix bugs in target-select-so-path.testAlexander Polyakov2018-09-252-6/+9
| | | | | | | | | | | | | | | | | | | | Summary: * This patch fixes hanging of the test in case of using python3, changes callback function that will be called if the timer ends, changes python interpreter to `%python` that is set up by llvm-lit. * Also, the test didn't work properly since it didn't contain a call of filecheck_proc.communicate(), that means that filecheck didn't run and its return code was equal to 0 in all cases. Reviewers: teemperor, labath, tatyana-krasnukha, aprantl Reviewed By: teemperor, labath Subscribers: ki.stfu, lldb-commits Differential Revision: https://reviews.llvm.org/D52498 llvm-svn: 343033
* Update a --help message and add -execute-only to the man page.Rui Ueyama2018-09-252-1/+4
| | | | llvm-svn: 343032
* Try to fix cosmetics to keep lines below 80 chars. NFC.Martin Storsjo2018-09-251-1/+1
| | | | | | | This should fix following buildbot errors: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/20371 llvm-svn: 343031
* AMDGPU: Add Selection patterns to support add of one bit.Changpeng Fang2018-09-252-0/+33
| | | | | | | | | | | | | | Summary: We generate s_xor to lower add of i1s in general cases, and s_not to lower add with a one-bit imm of -1 (true). Reviewers: rampitec Differential Revision: https://reviews.llvm.org/D52518 llvm-svn: 343030
OpenPOWER on IntegriCloud