summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [x86] add tests for extract of FP select; NFCSanjay Patel2019-03-091-0/+26
| | | | llvm-svn: 355768
* [ScalarizeMaskedMemIntrin] Use IRBuilder functions that take ↵Craig Topper2019-03-095-82/+68
| | | | | | | | | | | | uint32_t/uint64_t for getelementptr, extractelement, and insertelement. This saves needing to call getInt32 ourselves. Making the code a little shorter. The test changes are because insert/extract use getInt64 internally. Shouldn't be a functional issue. This cleanup because I plan to write similar code for expandload/compressstore. llvm-svn: 355767
* Actually implement the TestQueues.py workaroundFrederic Riss2019-03-091-5/+4
| | | | | | | | The code commited in r355764 didn't do what I want as I typed GetThreadID instead of GetQueueID. This commit contains a (hopefully) better version of the workaround. llvm-svn: 355766
* [CMake] Support stripping and linking output to .build-id directoryPetr Hosek2019-03-094-2/+54
| | | | | | | | | | | | | | | | | | | | | When installing runtimes with install-runtimes-stripped, we don't want to just strip them, we also want to preserve the debugging information for potential debugging. To make it possible to later find the stripped debugging information, we want to use the .build-id layout: https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID That is, for libfoo.so with build ID abcdef1234, the debugging information will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy already has support for stripping files and linking the debugging stripped output into the right location. However, CMake doesn't support customizing strip invocation for the *-stripped targets. So instead, we replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with the right command line flags. Differential Revision: https://reviews.llvm.org/D59127 llvm-svn: 355765
* Try to workaround the TestQueues.py flakynessFrederic Riss2019-03-091-0/+5
| | | | | | | | This is not a fix, but if I understand enough of the issue, it should bail out early of the test when in a situation that would result in a failure down the road. llvm-svn: 355764
* LWG 2843 "Unclear behavior of std::pmr::memory_resource::do_allocate()"Eric Fiselier2019-03-092-11/+15
| | | | | | | | | | | | | | | | | | | | Patch by Arthur O'Dwyer. Reviewed as https://reviews.llvm.org/D47344 new_delete_resource().allocate(n, a) has basically two permissible results: * Return an appropriately sized and aligned block. * Throw bad_alloc. Before this patch, libc++'s new_delete_resource would do a third and impermissible thing, which was to return an appropriately sized but inappropriately under-aligned block. This is now fixed. (This came up while I was stress-testing unsynchronized_pool_resource on my MacBook. If we can't trust the default resource to return appropriately aligned blocks, pretty much everything breaks. For similar reasons, I would strongly support just patching __libcpp_allocate directly, but I don't care to die on that hill, so I made this patch as a <memory_resource>-specific workaround.) llvm-svn: 355763
* 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
OpenPOWER on IntegriCloud