summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Break cycle lldb/Commands [3->] lldb/Expression [1->] lldb/CommandsJonas Devlieghere2019-03-093-21/+31
| | | | | | | | | | Inspired by Zachary's mail on lldb-dev, this seemed like low hanging fruit. This patch breaks the circular dependency between commands and expression. Differential revision: https://reviews.llvm.org/D59158 llvm-svn: 355762
* Add parens to force the order of operations in an expression tryingJason Molenda2019-03-091-1/+1
| | | | | | | | | | | to do "databuffer + offset" so that we don't overflow the uint64_t's we're using for addresses when working with high addresses. Found with clang's ubsan while doing darwin kernel debugging. <rdar://problem/48728940> llvm-svn: 355761
* Work around dllimport bug with exclude_from_explicit_instantiation.Eric Fiselier2019-03-081-0/+3
| | | | | | | | | | | | When dllimport is specified on a class, and exclude_from_explicit_instatiation is specified on a member, clang-cl will still expect a definition to be available externally. But this is not correct. Surprisingly one one symbol seems to be consistently affected by this bug. So this patch simply works around it there. llvm-svn: 355760
* Rename a local variable counter to Counter.Wei Mi2019-03-081-3/+3
| | | | llvm-svn: 355759
* Fix C++03 build failureEric Fiselier2019-03-081-1/+1
| | | | llvm-svn: 355758
* [RegisterCoalescer][NFC] bind a DenseMap access to a reference to avoidWei Mi2019-03-081-2/+3
| | | | | | repeated lookup operations llvm-svn: 355757
* Revert "[libc++] Do not force building with -fPIC"Eric Fiselier2019-03-081-0/+4
| | | | | | | | | | This reverts commit r355764. CMake does not turn -fPIC on for us by default. so this patch breaks standalone builds. The only reason it hasn't broken any bots is because LLVM turns on and specifies '-fPIC' for us. llvm-svn: 355756
* Unbork `std::memory_order` ABI.Eric Fiselier2019-03-081-6/+29
| | | | | | | | | | | | | | | | | | | Summary: We need to pin the underlying type of C++20' `std::memory_order` to match the C++17 version. Anything less is an ABI break. At the moment it's `unsigned` before C++20 and `int` after. Or if you're using `-fshort-enums` it's `unsigned char` before C++20 and `int` after. This patch explicitly specifies the underlying type of the C++20 `memory_order` to be w/e type the compiler would have chosen for the C++17 version. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: jfb, jdoerfert, #libc, zoecarver Differential Revision: https://reviews.llvm.org/D59063 llvm-svn: 355755
* [ScalarizeMaskedMemIntrin] Only set the ModifiedDT flag if new basic blocks ↵Craig Topper2019-03-081-12/+16
| | | | | | | | | | were added. There are special cases in the scalarization for constant masks. If we hit one of the special cases we don't need to reset the iteration. Noticed while starting work on adding expandload/compressstore to this pass. llvm-svn: 355754
* [RISCV] Allow access to FP CSRs without F extensionAna Pazos2019-03-085-32/+21
| | | | | | | | | | | | | | | | | | Summary: Floating-point CSRs should be accessible even when F extension is not enabled. But pseudo instructions that access floating point CSRs still require the F extension. GNU tools already implement this behavior. RISC-V spec is pending update to reflect this behavior and to extend it to pseudo instructions that access floating point CSRs. Reviewers: asb Reviewed By: asb Subscribers: asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, llvm-commits Differential Revision: https://reviews.llvm.org/D58932 llvm-svn: 355753
* Fix PR41017 - Build failure with _LIBCPP_DEBUG=0 and non-const-refEric Fiselier2019-03-082-7/+32
| | | | | | | | | | | comparator for std::sort() Our debug comparator assumed that the comparator it wraps would always accepts the values by const ref. This isn't required by the standard. This patch makes our __debug_less comparator forward the constness. llvm-svn: 355752
* [CodeGenPrepare] Fix ModifiedDT flag in optimizeSelectInstRong Xu2019-03-082-16/+44
| | | | | | | | | | | | | | | r44412 fixed a huge compile time regression but it needed ModifiedDT flag to be maintained correctly in optimizations in optimizeBlock() and optimizeInst(). Function optimizeSelectInst() does not update the flag. This patch propagates the flag in optimizeSelectInst() back to optimizeBlock(). This patch also removes ModifiedDT in CodeGenPrepare class (which is not used). The property of ModifiedDT is now recorded in a ref parameter. Differential Revision: https://reviews.llvm.org/D59139 llvm-svn: 355751
* [lldb] [test] Skip broken NetBSD core testMichal Gorny2019-03-081-0/+1
| | | | | | | Apparently the problem is harder than anticipated. Skip the test for now to fix buildbots. llvm-svn: 355750
* [Go / ASAN] Disable Go bindings for ASAN tests.Mitch Phillips2019-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Go binding tests fail under ASAN with the error at the bottom of this commit message. The reason the buildbots are not currently always failing on this test is that they selectively disable the bindings due to a Go binary not being present on their system. This change should allow users to build an asan-bootstrapped compiler and run asan-ified unit tests locally, similar to the way that sanitizer-* buildbots do. The error is: ``` FAIL: LLVM :: Bindings/Go/go.test (7050 of 30112) ******************** TEST 'LLVM :: Bindings/Go/go.test' FAILED ******************** Script: -- : 'RUN: at line 1'; /usr/local/google/home/mitchp/llvm-build/asan/sanitized-clang/bin/llvm-go go=/usr/lib/google-golang/bin/go test llvm.org/llvm/bindings/go/llvm -- Exit Code: 1 Command Output (stdout): -- FAIL llvm.org/llvm/bindings/go/llvm [build failed] -- Command Output (stderr): -- ld.lld: error: undefined symbol: std::allocator<char>::allocator() >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(LLVMAddDataFlowSanitizerPass) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(LLVMAddDataFlowSanitizerPass) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(LLVMAddDataFlowSanitizerPass) ld.lld: error: undefined symbol: std::allocator<char>::~allocator() >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(LLVMAddDataFlowSanitizerPass) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(LLVMAddDataFlowSanitizerPass) ld.lld: error: undefined symbol: std::allocator<char>::~allocator() >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(LLVMAddDataFlowSanitizerPass) ld.lld: error: undefined symbol: llvm::createDataFlowSanitizerPass(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, void* (*)(), void* (*)()) >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(LLVMAddDataFlowSanitizerPass) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(void std::_Destroy<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(void __gnu_cxx::new_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::construct<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&)) ld.lld: error: undefined symbol: std::__throw_length_error(char const*) >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_check_len(unsigned long, char const*) const) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(void std::_Construct<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&)) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() >>> referenced by InstrumentationBindings.cpp >>> $WORK/b048/_x018.o:(void __gnu_cxx::new_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::destroy<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string() >>> referenced by SupportBindings.cpp >>> $WORK/b048/_x019.o:(LLVMLoadLibraryPermanently2) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::size() const >>> referenced by SupportBindings.cpp >>> $WORK/b048/_x019.o:(LLVMLoadLibraryPermanently2) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::c_str() const >>> referenced by SupportBindings.cpp >>> $WORK/b048/_x019.o:(LLVMLoadLibraryPermanently2) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::size() const >>> referenced by SupportBindings.cpp >>> $WORK/b048/_x019.o:(LLVMLoadLibraryPermanently2) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() >>> referenced by SupportBindings.cpp >>> $WORK/b048/_x019.o:(LLVMLoadLibraryPermanently2) ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() >>> referenced by SupportBindings.cpp >>> $WORK/b048/_x019.o:(LLVMLoadLibraryPermanently2) ld.lld: error: undefined symbol: llvm::sys::DynamicLibrary::getPermanentLibrary(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) >>> referenced by SupportBindings.cpp >>> $WORK/b048/_x019.o:(llvm::sys::DynamicLibrary::LoadLibraryPermanently(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)) ld.lld: error: undefined symbol: __asan_option_detect_stack_use_after_return >>> referenced by MCJIT.cpp:45 (/usr/local/google/home/mitchp/llvm/llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp:45) >>> MCJIT.cpp.o:(llvm::MCJIT::createJIT(std::__1::unique_ptr<llvm::Module, std::__1::default_delete<llvm::Module> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, std::__1::shared_ptr<llvm::MCJITMemoryManager>, std::__1::shared_ptr<llvm::LegacyJITSymbolResolver>, std::__1::unique_ptr<llvm::TargetMachine, std::__1::default_delete<llvm::TargetMachine> >)) in archive /usr/local/google/home/mitchp/llvm-build/asan/sanitized-clang/lib/libLLVMMCJIT.a ld.lld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors) clang-9: error: linker command failed with exit code 1 (use -v to see invocation) -- ``` llvm-svn: 355749
* [LLD] Fixed flaky unit test based on build directory.Mitch Phillips2019-03-081-0/+1
| | | | | | | | | | This unit test fails if 'zed' appears in your build path, as lld is echoing out the path of the source file. Change the unit test to explicitly only match everything after the 'Symbols [' line of the output, to make sure that this test doesn't inadvertently fail due to the build path. llvm-svn: 355748
* [lldb] [test] Do not check libc function names in NetBSD core testMichal Gorny2019-03-081-1/+1
| | | | | | | | | Fix the NetBSD core test not to verify libc function names in backtrace. This obviously requires the same libc.so as originally used to produce the core file, and so it is going to fail everywhere except on my system. llvm-svn: 355747
* [libc++] Do not force building with -fPICLouis Dionne2019-03-081-4/+0
| | | | | | | | | | | | | | | | Summary: Whether we build with -fPIC should be specified by the CMAKE_POSITION_INDEPENDENT_CODE option at configure time. Note that this patch doesn't change the behavior when building by default, since -fPIC is used for shared libraries by default. Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59146 llvm-svn: 355746
* [AArch64][GlobalISel] Fix i1 arguments not being zero-extended as required ↵Amara Emerson2019-03-082-0/+12
| | | | | | | | by ABI. Fixes PR41001. llvm-svn: 355745
* [8.0 Regression] Fix handling of `__builtin_constant_p` inside template ↵Eric Fiselier2019-03-083-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arguments, enumerators, case statements, and the enable_if attribute. Summary: The following code is accepted by Clang 7 and prior but rejected by the upcoming 8 release and in trunk [1] ``` // error {{never produces a constant expression}} void foo(const char* s) __attribute__((enable_if(__builtin_constant_p(*s) == false, "trap"))) {} void test() { foo("abc"); } ``` Prior to Clang 8, the call to `__builtin_constant_p` was a constant expression returning false. Currently, it's not a valid constant expression. The bug is caused because we failed to set `InConstantContext` when attempting to evaluate unevaluated constant expressions. [1] https://godbolt.org/z/ksAjmq Reviewers: rsmith, hans, sbenza Reviewed By: rsmith Subscribers: kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59038 llvm-svn: 355743
* Improve "llvm-nm -f sysv" output for Elf filesSunil Srivastava2019-03-087-18/+77
| | | | | | | | | | Specifically, compute and Print Type and Section columns. This is a re-commit of rL354833, after fixing the Asan problem found a a buildbot. Differential Revision: https://reviews.llvm.org/D59060 llvm-svn: 355742
* [x86] scalarize extract element 0 of FP cmpSanjay Patel2019-03-083-294/+132
| | | | | | | | | | | | | An extension of D58282 noted in PR39665: https://bugs.llvm.org/show_bug.cgi?id=39665 This doesn't answer the request to use movmsk, but that's an independent problem. We need this and probably still need scalarization of FP selects because we can't do that as a target-independent transform (although it seems likely that targets besides x86 should have this transform). llvm-svn: 355741
* [NVPTX][DEBUGINFO]Temp workaround for crash of ptxas: disable packed bytes ↵Alexey Bataev2019-03-087-546/+4480
| | | | | | | | | | | | | | | | | | | in debug sections. Summary: This patch works around the bug in the ptxas tool with the processing of bytes separated by the comma symbol. The emission of the packed string is temporarily disabled. Reviewers: tra Subscribers: jholewinski, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59148 llvm-svn: 355740
* [OpenMP][stats] Update stats gathering macrosJonathan Peyton2019-03-082-16/+16
| | | | llvm-svn: 355739
* [HWASan] Save + print registers when tag mismatch occurs in AArch64.Mitch Phillips2019-03-0810-12/+251
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change change the instrumentation to allow users to view the registers at the point at which tag mismatch occured. Most of the heavy lifting is done in the runtime library, where we save the registers to the stack and emit unwind information. This allows us to reduce the overhead, as very little additional work needs to be done in each __hwasan_check instance. In this implementation, the fast path of __hwasan_check is unmodified. There are an additional 4 instructions (16B) emitted in the slow path in every __hwasan_check instance. This may increase binary size somewhat, but as most of the work is done in the runtime library, it's manageable. The failure trace now contains a list of registers at the point of which the failure occured, in a format similar to that of Android's tombstones. It currently has the following format: Registers where the failure occurred (pc 0x0055555561b4): x0 0000000000000014 x1 0000007ffffff6c0 x2 1100007ffffff6d0 x3 12000056ffffe025 x4 0000007fff800000 x5 0000000000000014 x6 0000007fff800000 x7 0000000000000001 x8 12000056ffffe020 x9 0200007700000000 x10 0200007700000000 x11 0000000000000000 x12 0000007fffffdde0 x13 0000000000000000 x14 02b65b01f7a97490 x15 0000000000000000 x16 0000007fb77376b8 x17 0000000000000012 x18 0000007fb7ed6000 x19 0000005555556078 x20 0000007ffffff768 x21 0000007ffffff778 x22 0000000000000001 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007ffffff6f0 x30 00000055555561b4 ... and prints after the dump of memory tags around the buggy address. Every register is saved exactly as it was at the point where the tag mismatch occurs, with the exception of x16/x17. These registers are used in the tag mismatch calculation as scratch registers during __hwasan_check, and cannot be saved without affecting the fast path. As these registers are designated as scratch registers for linking, there should be no important information in them that could aid in debugging. Reviewers: pcc, eugenis Reviewed By: pcc, eugenis Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, hiraditya, jdoerfert, llvm-commits, #sanitizers Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58857 llvm-svn: 355738
* [WebAssembly] Don't mark lazy symbols as `IsUsedInRegularObj`Sam Clegg2019-03-084-8/+14
| | | | | | | | | | | This matches the ELF does. Update the comment in ELF/Symbols.h and duplicate it in wasm/Symbols.h This a followup on rL355580 and rL355577. Differential Revision: https://reviews.llvm.org/D59075 llvm-svn: 355737
* [lldb] [Process] Add proper support for NetBSD core files with threadsMichal Gorny2019-03-0813-30/+507
| | | | | | | | | | | | | | Improve the support for processing NetBSD cores. Fix reading process identifier, thread information and associating the terminating signal with the correct thread. Includes test cases for single-threaded program receiving SIGSEGV, and two dual-threaded programs: one where thread receives the signal, and the other one when the whole process is signalled. Differential Revision: https://reviews.llvm.org/D32149 llvm-svn: 355736
* [cmake] Remove llvm from LLVM_ALL_PROJECTSShoaib Meenai2019-03-081-1/+1
| | | | | | | | | | | LLVM is always built; including it in LLVM_ENABLE_PROJECTS has no effect, but since it's in LLVM_ALL_PROJECTS, we produce a confusing message about it being disabled. Drop it from LLVM_ALL_PROJECTS to avoid this. Pointed out by David Greene on the mailing list [1]. [1] http://lists.llvm.org/pipermail/llvm-dev/2019-March/130854.html llvm-svn: 355735
* [GN] Merge 355720.Mitch Phillips2019-03-081-0/+1
| | | | llvm-svn: 355734
* [RegionPass] Fix forgotten "!".Michael Kruse2019-03-081-1/+1
| | | | | | | | | | | | Commit r355068 "Fix IR/Analysis layering issue with OptBisect" uses the template return Gate.isEnabled() && !Gate.shouldRunPass(this, getDescription(...)); for all pass kinds. For the RegionPass, it left out the not operator, causing region passes to be skipped as soon as a pass gate is used. llvm-svn: 355733
* [NFC] Add missing revision information to ABI ChangelogLouis Dionne2019-03-081-1/+1
| | | | llvm-svn: 355732
* AMDGPU: Move d16 load matching to preprocess stepMatt Arsenault2019-03-0813-198/+490
| | | | | | | | | | | | | | | | | When matching half of the build_vector to a load, there could still be a hidden dependency on the other half of the build_vector the pattern wouldn't detect. If there was an additional chain dependency on the other value, a cycle could be introduced. I don't think a tablegen pattern is capable of matching the necessary conditions, so move this into PreprocessISelDAG. Check isPredecessorOf for the other value to avoid a cycle. This has a warning that it's expensive, so this should probably be moved into an MI pass eventually that will have more freedom to reorder instructions to help match this. That is currently complicated by the lack of a computeKnownBits type mechanism for the selected function. llvm-svn: 355731
* Remove dependency edges from Host to Target/Core.Zachary Turner2019-03-082-2/+0
| | | | | | After recent changes, Host is now dependency-free. llvm-svn: 355730
* [OPENMP]Remove debug service variable.Alexey Bataev2019-03-082-16/+1
| | | | | | Removed not required service variable for the debug info. llvm-svn: 355729
* DAG: Don't try to cluster loads with tied inputsMatt Arsenault2019-03-083-47/+57
| | | | | | | | | | | | | | | | | | | | | This avoids breaking possible value dependencies when sorting loads by offset. AMDGPU has some load instructions that write into the high or low bits of the destination register, and have a tied input for the other input bits. These can easily have the same base pointer, but be a swizzle so the high address load needs to come first. This was inserting glue forcing the opposite ordering, producing a cycle the InstrEmitter would assert on. It may be potentially expensive to look for the dependency between the other loads, so just skip any where this could happen. Fixes bug 40936 by reverting r351379, which added a hacky attempt to fix this by adding chains in this case, which I think was just working around broken glue before the InstrEmitter. The core of the patch is re-implementing the fix for that problem. llvm-svn: 355728
* [x86] add tests for extracted vector FP cmp; NFCSanjay Patel2019-03-081-0/+25
| | | | llvm-svn: 355727
* [docs] Fix checkers.rst doc for PointerSorting checkerMandeep Singh Grang2019-03-081-1/+1
| | | | llvm-svn: 355726
* Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"Matthew Voss2019-03-0811-51/+32
| | | | | | | | This broke the windows bots. This reverts commit 28302c66d2586074f77497d5dc4eac7182b679e0. llvm-svn: 355725
* AMDGPU: Add more tests for d16 loadsMatt Arsenault2019-03-082-210/+868
| | | | | | Also fix a few cases that weren't testing what they were supposed to. llvm-svn: 355724
* AMDGPU: Don't bother checking the chain in areLoadsFromSameBasePtrMatt Arsenault2019-03-081-15/+0
| | | | | | | This is only called in contexts that are verifying the chain itself, and the query itself is only asking about the address. llvm-svn: 355723
* AMDGPU: Correct DS implementation of areLoadsFromSameBasePtrMatt Arsenault2019-03-082-6/+6
| | | | | | | | | This was checking the wrong operands for the base register and the offsets. The indexes are shifted by the number of output registers from the machine instruction definition, and the chain is moved to the end. llvm-svn: 355722
* Revert "Recommit "Support attribute used in member funcs of class templates""Rafael Auler2019-03-082-33/+0
| | | | | | | | | There is nontrivial bug caused in lld that I need to further investigate. Meanwhile, I'll revert this. This reverts commit 8297e93480c636dc90fd14653c5a66406193363f. llvm-svn: 355721
* [Analyzer] Checker for non-determinism caused by sorting of pointer-like ↵Mandeep Singh Grang2019-03-087-0/+222
| | | | | | | | | | | | | | | | | | | | elements Summary: Added a new category of checkers for non-determinism. Added a checker for non-determinism caused due to sorting containers with pointer-like elements. Reviewers: NoQ, george.karpenkov, whisperity, Szelethus Reviewed By: NoQ, Szelethus Subscribers: Charusso, baloghadamsoftware, jdoerfert, donat.nagy, dkrupp, martong, dblaikie, MTC, Szelethus, mgorny, xazax.hun, szepet, rnkovacs, a.sidorin, mikhail.ramalho, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D50488 llvm-svn: 355720
* [DEBUG_INFO][NVPTX]Emit empty .debug_loc section in presence of the debug ↵Alexey Bataev2019-03-082-1/+5
| | | | | | | | | | | | | | | | | | | | option. Summary: If the LLVM module shows that it has debug info, but the file is actually empty and the real debug info is not emitted, the ptxas tool emits error 'Debug information not found in presence of .target debug'. We need at leas one empty debug section to silence this message. Section `.debug_loc` is not emitted for PTX and we can emit empty `.debug_loc` section if `debug` option was emitted. Reviewers: tra Subscribers: jholewinski, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D57250 llvm-svn: 355719
* [msan] Properly guard tests added by r355348; NFCHubert Tong2019-03-081-4/+2
| | | | | | | r355348 uses builtins without proper guards, breaking the test on various platforms. llvm-svn: 355718
* [TSan] Initialize libdispatch interceptors if necessaryJulian Lettner2019-03-082-0/+46
| | | | | | | | | | | | On Linux (and other non-Darwin platforms) we need to initialize interceptors. Since tsan_libdispatch.cc is compiled optionally, add a weak default implementation of `InitializeLibdispatchInterceptors`. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D59113 llvm-svn: 355717
* [DAGCombiner] fold (add (add (xor a, -1), b), 1) -> (sub b, a)Amaury Sechet2019-03-083-32/+37
| | | | | | | | | | | | | | Summary: This pattern is sometime created after legalization. Reviewers: efriedma, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58874 llvm-svn: 355716
* [CFLAnders] Fix typo in comment; NFCGeorge Burgess IV2019-03-081-1/+1
| | | | | | | | Patch by Enna1! Differential Revision: https://reviews.llvm.org/D58756 llvm-svn: 355715
* [RegisterCoalescer] Limit the number of joins for large live interval withWei Mi2019-03-081-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | many valnos. Recently we found compile time out problem in several cases when SpeculativeLoadHardening was enabled. The significant compile time was spent in register coalescing pass, where register coalescer tried to join many other live intervals with some very large live intervals with many valnos. Specifically, every time JoinVals::mapValues is called, computeAssignment will be called by getNumValNums() times of the target live interval. If the large live interval has N valnos and has N copies associated with it, trying to coalescing those copies will at least cost N^2 complexity. The patch adds some limit to the effort trying to join those very large live intervals with others. By default, for live interval with > 100 valnos, and when it has been coalesced with other live interval by more than 100 times, we will stop coalescing for the live interval anymore. That put a compile time cap for the N^2 algorithm and effectively solves the compile time problem we saw. Differential revision: https://reviews.llvm.org/D59143 llvm-svn: 355714
* [x86] prevent infinite looping from inverse shuffle transformsSanjay Patel2019-03-082-1/+18
| | | | llvm-svn: 355713
* [X86] Add test case for PR22473Simon Pilgrim2019-03-081-0/+22
| | | | llvm-svn: 355712
OpenPOWER on IntegriCloud