summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [Reproducers] Properly handle QEnvironment packetsJonas Devlieghere2019-03-212-1/+16
| | | | | | | | On Linux, a QEnvironment packet is sent for every environment variable. This breaks replay when the number of environment variables is different then during capture. The solution is to always reply with OK. llvm-svn: 356643
* [instcombine] Add some todos, and arrange code for readibilityPhilip Reames2019-03-212-32/+38
| | | | llvm-svn: 356642
* [MSSA] Delete move ctor; remove dynamic never-moved verificationGeorge Burgess IV2019-03-212-16/+5
| | | | | | | | | | | | | | | | Code archaeology in D59315 revealed that MSSA should never be moved. Rather than trying to check dynamically that this hasn't happened in the verify() functions of Walkers, it's likely best to just delete its move constructor. Since all these verify() functions did is check that MSSA hasn't moved, this allows us to remove these verify functions. I can readd the verification checks if someone's super concerned about us trying to `memcpy` MemorySSA or something somewhere, but I imagine we have other problems if we're trying anything like that... llvm-svn: 356641
* Add dylib-has-no-filesystem when filesystem is disabledEric Fiselier2019-03-211-0/+2
| | | | llvm-svn: 356640
* Mark debug death tests as unsupported on WindowsEric Fiselier2019-03-2111-2/+11
| | | | llvm-svn: 356639
* [Reproducers] Log inconsistencies during replay (NFC)Jonas Devlieghere2019-03-212-5/+41
| | | | | | | | Make debugging of the GDB remote packet aspect of reproducers easier by logging both requests and replies. This enables some sanity checking during replay. llvm-svn: 356638
* Remove type visibility specifiers from new chrono types.Eric Fiselier2019-03-211-18/+18
| | | | | | | | | _LIBCPP_TYPE_VIS is only really needed on types with a vtable. And on Windows it doesn't work with types that have only inline methods. This patch removes the unneeded attributes. llvm-svn: 356637
* creduce-clang-crash.py: preprocess file + reduce commandlineGeorge Burgess IV2019-03-211-72/+194
| | | | | | | | | | | | | | | | | | This CL causes our creduce-clang-crash.py util to: - try to preprocess the file before reducing - try to remove some command line arguments - now require a llvm bin directory, since the generated crash script doesn't have an absolute path for clang It also marks it as executable, since I forgot to do that in the last commit. :) Patch by Amy Huang! Differential Revision: https://reviews.llvm.org/D59440 llvm-svn: 356636
* [libcxx] [test] Revert r356632 add (void) casts to operator new calls, to ↵Billy Robert O'Neal III2019-03-216-6/+6
| | | | | | suppress warnings generated by [[nodiscard]]." llvm-svn: 356635
* [CFG] [analyzer] pr41142: C++17: Skip transparent InitListExprs in constructors.Artem Dergachev2019-03-213-0/+47
| | | | | | | | | | | | | | When searching for construction contexts, i.e. figuring out which statements define the object that is constructed by each construct-expression, ignore transparent init-list expressions because they don't add anything to the context. This allows the Static Analyzer to model construction, destruction, materialization, lifetime extension correctly in more cases. Also fixes a crash caused by incorrectly evaluating initial values of variables initialized with such expressions. Differential Revision: https://reviews.llvm.org/D59573 llvm-svn: 356634
* Allow disabling of filesystem library.Eric Fiselier2019-03-218-8/+33
| | | | | | | | | | | | | | Summary: Filesystem doesn't work on Windows, so we need a mechanism to turn it off for the time being. Reviewers: ldionne, serge-sans-paille, EricWF Reviewed By: EricWF Subscribers: mstorsjo, mgorny, christof, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59619 llvm-svn: 356633
* [libcxx] [test] Add (void) casts to operator new calls, to suppress warnings ↵Billy Robert O'Neal III2019-03-206-6/+6
| | | | | | | | generated by [[nodiscard]]. This allows these tests to pass when compiled by MSVC++. llvm-svn: 356632
* [X86] Add CMPXCHG8B feature flag. Set it for all CPUs except i386/i486 ↵Craig Topper2019-03-208-48/+719
| | | | | | | | | | | | including 'generic'. Disable use of CMPXCHG8B when this flag isn't set. CMPXCHG8B was introduced on i586/pentium generation. If its not enabled, limit the atomic width to 32 bits so the AtomicExpandPass will expand to lib calls. Unclear if we should be using a different limit for other configs. The default is 1024 and experimentation shows that using an i256 atomic will cause a crash in SelectionDAG. Differential Revision: https://reviews.llvm.org/D59576 llvm-svn: 356631
* Revert "Reland r356547 after fixing the tests for Linux."Douglas Yung2019-03-201-144/+26
| | | | | | | | | This reverts commit 538fb72226cf6dff95af83f7777e12b8dbd061ea (r356565). This is still breaking a build bot: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/45557 llvm-svn: 356630
* Fix Mach-O bind and rebase validation errors in libObjectMichael Trent2019-03-204-195/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: llvm-objdump (via libObject) validates DYLD_INFO rebase and bind entries against the basic structure found in the Mach-O file before evaluating the contents of those entries. Certain malformed Mach-Os can defeat the validation check and force llvm-objdump (libObject) to crash. The previous logic verified a rebase or bind started in a valid Mach-O section, but did not verify that the section wholely contained the fixup. It also generally allows rebases or binds to start immediately after a valid section even if that range is not itself part of a valid section. Finally, bind and rebase opcodes that indicate more than one fixup (apply N times...) are not completely validated: only the first and final fixups are checked. The previous logic also rejected certain binaries as false positives. Some bind and rebase opcodes can modify the state machine such that the next bind or rebase will fail. libObject will reject these opcodes as invalid in order to be helpful and print an error message associated with the instruction that caused the problem, even though the binary is not actually illegal until it consumes the invalid state in the state machine. In other words, libObject may reject a Mach-O binary that Apple's dynamic linker may consider legal. The original version of macho-rebase-add-addr-uleb-too-big is an example of such a binary. I have replaced the existing checkSegAndOffset and checkCountAndSkip functions with a single function, checkSegAndOffsets, which validates all of the fixups realized by a DYLD_INFO opcode. checkSegAndOffsets verifies that a Mach-O section fully contains each fixup. Every fixup realized by an opcode is validated, and some (but not all!) inconsistencies in the state machine are allowed until a fixup is realized. This means that libObject may fail on an opcode that realizes a fixup, not on the opcode that introduced the arithmetic error. Existing test cases have been modified to reflect the changes in error messages returned by libObject. What's more, the test case for macho-rebase-add-addr-uleb-too-big has been modified so that it actually triggers the error condition; the new code in libObject considers the original test binary "legal". rdar://47797757 Reviewers: lhames, pete, ab Reviewed By: pete Subscribers: rupprecht, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59574 llvm-svn: 356629
* Remove extra white spacesJennifer Yu2019-03-201-2/+2
| | | | llvm-svn: 356628
* [clang-tidy] Disable google-runtime-int in Objective-C++ 🔓Stephane Moore2019-03-203-1/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In contrast to Google C++, Objective-C often uses built-in integer types other than `int`. In fact, the Objective-C runtime itself defines the types NSInteger¹ and NSUInteger² which are variant types depending on the target architecture. The Objective-C style guide indicates that usage of system types with variant sizes is appropriate when handling values provided by system interfaces³. Objective-C++ is commonly the result of conversion from Objective-C to Objective-C++ for the purpose of integrating C++ functionality. The opposite of Objective-C++ being used to expose Objective-C functionality to C++ is less common, potentially because Objective-C has a signficantly more uneven presence on different platforms compared to C++. This generally predisposes Objective-C++ to commonly being more Objective-C than C++. Forcing Objective-C++ developers to perform conversions between variant system types and fixed size integer types depending on target architecture when Objective-C++ commonly uses variant system types from Objective-C is likely to lead to more bugs and overhead than benefit. For that reason, this change proposes to disable google-runtime-int in Objective-C++. [1] https://developer.apple.com/documentation/objectivec/nsinteger?language=objc [2] https://developer.apple.com/documentation/objectivec/nsuinteger?language=objc [3] "Types long, NSInteger, NSUInteger, and CGFloat vary in size between 32- and 64-bit builds. Use of these types is appropriate when handling values exposed by system interfaces, but they should be avoided for most other computations." https://github.com/google/styleguide/blob/gh-pages/objcguide.md#types-with-inconsistent-sizes Subscribers: xazax.hun, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59336 llvm-svn: 356627
* Change the logging on ptrace(PT_KILL) in MachProcess::Kill to logJason Molenda2019-03-201-3/+5
| | | | | | | | if LOG_PROCESS is enabled or if there was an error making that call. <rdar://problem/49036508> llvm-svn: 356626
* Update DWARF files.Jason Molenda2019-03-201-12/+6
| | | | llvm-svn: 356625
* libc++/win: Make once_flag have the same size as a pointer.Nico Weber2019-03-202-13/+22
| | | | | | | | | | | | | | | | | | | | | | `unsigned long` is 32-bit on 32-bit systems and 64-bit on 64-bit systems on LP64 systems -- which most Unix systems are, but Windows isn't. Windows is LLP64, which means unsigned long is 32-bit even on 64-bit systems. pplwin.h contains static_assert(alignof(void *) == alignof(::std::once_flag), ...) which fails due to this problem. Instead of unsigned long, use uintptr_t, which consistently is 32-bit on 32-bit systems and 64-bit on 64-bit systems. No functional change except on 64-bit Windows. Differential Revision: https://reviews.llvm.org/D59607 llvm-svn: 356624
* Revert "[clangd] Print arguments in template specializations"Jordan Rupprecht2019-03-207-140/+64
| | | | | | This reverts commit 44a63f6a150dec72dea43730d2a89d292e58bd6f. It segfaults on an internal test case (will follow up off thread). llvm-svn: 356623
* [WebAssembly][NFC] Fix formatting error from rL356610Thomas Lively2019-03-201-2/+3
| | | | llvm-svn: 356622
* [AMDGPU] Do not generate spurious PAL metadataTim Renouf2019-03-203-6/+18
| | | | | | | | | | | | My previous fix rL356591 "[AMDGPU] Added MsgPack format PAL metadata" accidentally caused a spurious PAL metadata .note record to be emitted for any AMDGPU output. That caused failures in the lld test amdgpu-relocs.s. Fixed. Differential Revision: https://reviews.llvm.org/D59613 Change-Id: Ie04a2aaae890dcd490f22c89edf9913a77ce070e llvm-svn: 356621
* [InstCombine] Add additional sub nsw inference tests; NFCNikita Popov2019-03-201-2/+28
| | | | | | | nsw can be determined based on known bits here, but currently isn't. llvm-svn: 356620
* Allow machine dce to remove uses in the same instructionStanislav Mekhanoshin2019-03-202-3/+60
| | | | | | | | | | | | | | | | Machine DCE cannot remove a dead definition if there are non-dbg uses. A use however can be in the same instruction: dead %0 = INST %0 Such instructions sometimes created by Detect dead lanes pass. Allow this instruction to be deleted despite the use if the only use belongs to the same instruction. Differential Revision: https://reviews.llvm.org/D59565 llvm-svn: 356619
* [X86] Call lowerShuffleAsBitMask for 512-bit vectors in lowerShuffleAsBlend.Craig Topper2019-03-204-158/+185
| | | | | | | | | | | | | | | | | This patch enables the use of lowerShuffleAsBitMask for 512-bit blends before falling back to move immedate, GPR to k-register, and masked op. I had to make some changes to support v8i64 when i64 is not a legal type. And to support floating point types. This trades a load for the move immediate and GPR move which is higher latency. But its probably better for register pressure not having to hop through other register classes. The load+and should play better with LICM and rematerialization I think. Differential Revision: https://reviews.llvm.org/D59479 llvm-svn: 356618
* [AMDGPU] Fix dependency on `BinaryFormat`Michael Liao2019-03-201-1/+1
| | | | | | | | | | | | Summary: - The linking is broken when this library is built as shared one. Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59610 llvm-svn: 356617
* [libc++] Mark <filesystem> as unavailable on Apple platforms using pragmasLouis Dionne2019-03-206-3/+30
| | | | | | | | | | | | | | | | | | | | | Summary: Also add the corresponding XFAILs to tests that require filesystem. The approach taken to mark <filesystem> as unavailable in this patch is to mark all the header as unavailable using #pragma clang attribute. Marking each declaration using the attribute is more intrusive and does not provide a lot of value right now because pretty much everything in <filesystem> requires dylib support, often transitively. This is an alternative to https://reviews.llvm.org/D59093. A similar (but partial) patch was already applied in r356558. Reviewers: mclow.lists, EricWF, serge-sans-paille Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59224 llvm-svn: 356616
* [clang-format][NFC] fix release notes build issuePaul Hoad2019-03-201-1/+1
| | | | | | build issue from r356613 llvm-svn: 356615
* [clang][OpenMP] Fix build when using libgompJordan Rupprecht2019-03-201-1/+1
| | | | | | | | | | | | | | Summary: rL356570 introduced a test which only passes with the default openmp library, libomp, and fails with other openmp libraries, such as libgomp. Explicitly choose libomp. Reviewers: lebedev.ri Subscribers: guansong, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59609 llvm-svn: 356614
* [clang-format] BeforeHash added to IndentPPDirectivesPaul Hoad2019-03-208-29/+157
| | | | | | | | | | | | | | | | | | Summary: The option BeforeHash added to IndentPPDirectives. Fixes Bug 36019. https://bugs.llvm.org/show_bug.cgi?id=36019 Reviewers: djasper, klimek, krasimir, sammccall, mprobst, Nicola, MyDeveloperDay Reviewed By: klimek, MyDeveloperDay Subscribers: kadircet, MyDeveloperDay, mnussbaum, geleji, ufna, cfe-commits Patch by to-mix. Differential Revision: https://reviews.llvm.org/D52150 llvm-svn: 356613
* Introduce DWARFContext.Zachary Turner2019-03-208-54/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLVM's DWARF parsing library has a class called DWARFContext which holds all of the various DWARF data sections and lots of other information. LLDB's on the other hand stores all of this directly in SymbolFileDWARF / SymbolFileDWARFDwo and passes this interface around through the parsing library. Obviously this is incompatible with a world where the low level interface does not depend on the high level interface, so we need to move towards a model similar to LLVM's - i.e. all of the context needed for low level parsing should be in a single class, and that class gets passed around. This patch is a small incremental step towards achieving this. The interface and internals deviate from LLVM's for technical reasons, but the high level idea is the same. The goal is, eventually, to remove all occurrences of SymbolFileDWARF from the low level parsing code. For now I've chosen a very simple section - the .debug_aranges section to move into DWARFContext while leaving everything else unchanged. In the short term this is a bit confusing because now the information you need might come from either of 2 different locations. But it's a huge refactor to do this all at once and runs a much higher risk of breaking things. So I think it would be wise to do this in very small pieces. TL;DR - No functional change Differential Revision: https://reviews.llvm.org/D59562 llvm-svn: 356612
* AMDGPU: Don't look for constant in insert/extract_vector_elt regbankselectMatt Arsenault2019-03-203-119/+153
| | | | | | | | | The constantness shouldn't change the register bank choice. We also don't need to restrict this to only indexing VGPRs, since it's possible to index SGPRs (but SelectionDAG made using this difficult). Allow directly indexing SGPRs when appropriate. llvm-svn: 356611
* [WebAssembly] Target features sectionThomas Lively2019-03-2033-10/+611
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implements a new target features section in assembly and object files that records what features are used, required, and disallowed in WebAssembly objects. The linker uses this information to ensure that all objects participating in a link are feature-compatible and records the set of used features in the output binary for use by optimizers and other tools later in the toolchain. The "atomics" feature is always required or disallowed to prevent linking code with stripped atomics into multithreaded binaries. Other features are marked used if they are enabled globally or on any function in a module. Future CLs will add linker flags for ignoring feature compatibility checks and for specifying the set of allowed features, implement using the presence of the "atomics" feature to control the type of memory and segments in the linked binary, and add front-end flags for relaxing the linkage policy for atomics. Reviewers: aheejin, sbc100, dschuff Subscribers: jgravelle-google, hiraditya, sunfish, mgrang, jfb, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59173 llvm-svn: 356610
* [X86] Add __crc32b/__crc32w/__crc32d/__crc32q intrinsics to match gcc and icc.Craig Topper2019-03-202-0/+116
| | | | | | | | | gcc has these intrinsics in ia32intrin.h as well. And icc implements them though they aren't documented in the Intel Intrinsics Guide. Differential Revision: https://reviews.llvm.org/D59533 llvm-svn: 356609
* [AMDGPU] Fix clamp bit DAG operandMichael Liao2019-03-202-5/+30
| | | | | | | | | | | | | | | | | | Summary: - Should use `targetconstant` instead of `constant` operand for clamp bit, which is expected as an immediate operand. Under certain conditions, such as a common `i1 false` constant is used in other place and selected before the instruction with clamp bit, register operand may be added instead of immediate one. Use `targetcosntant` to enforce that. Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59608 llvm-svn: 356608
* [OPENMP]Improve detection of omp_allocator_handle_t type and predefinedAlexey Bataev2019-03-207-37/+148
| | | | | | | | | | | allocators. It is better to deduce omp_allocator_handle_t type from the predefined allocators, because omp.h header might not define it explicitly. Plus, it allows to identify the predefined allocators correctly when trying to build the allcoator for the global variables. llvm-svn: 356607
* [ARC] Add ARCOptAddrMode pass to generate postincrement loads/stores.Pete Couperus2019-03-206-2/+582
| | | | | | | | | | Build on newly introduced ARC postincrement loads/stores from r356200. Patch By Denis Antrushin! <denis@synopsys.com> Differential Revision: https://reviews.llvm.org/D59409 llvm-svn: 356606
* Fix implicit ios -> watchOS availability version mapping forAlex Lorenz2019-03-202-0/+7
| | | | | | | | versions that have the major number only rdar://48018651 llvm-svn: 356605
* [AArch64] Fix formatting (NFC)Evandro Menezes2019-03-201-21/+22
| | | | | | Indent macro instances properly. llvm-svn: 356604
* AMDHSA: Fix COMPUTE_PGM_RSRC2.USER_SGPR calculation when parsing ISA assemblyKonstantin Zhuravlyov2019-03-202-8/+8
| | | | | | | | It must match https://llvm.org/docs/AMDGPUUsage.html#initial-kernel-execution-state Differential Revision: https://reviews.llvm.org/D59570 llvm-svn: 356603
* Mark <charconv> tests as unsupported for C++11 and C++14 if you're not ↵Marshall Clow2019-03-204-0/+8
| | | | | | testing libc++. Thanks to Louis for the suggestion. llvm-svn: 356602
* [ARM] Eliminate redundant "mov rN, sp" instructions in Thumb1.Eli Friedman2019-03-206-46/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This takes sequences like "mov r4, sp; str r0, [r4]", and optimizes them to something like "str r0, [sp]". For regular stack variables, this optimization was already implemented: we lower loads and stores using frame indexes, which are expanded later. However, when constructing a call frame for a call with more than four arguments, the existing optimization doesn't apply. We need to use stores which are actually relative to the current value of sp, and don't have an associated frame index. This patch adds a special case to handle that construct. At the DAG level, this is an ISD::STORE where the address is a CopyFromReg from SP (plus a small constant offset). This applies only to Thumb1: in Thumb2 or ARM mode, a regular store instruction can access SP directly, so the COPY gets eliminated by existing code. The change to ARMDAGToDAGISel::SelectThumbAddrModeSP is a related cleanup: we shouldn't pretend that it can select anything other than frame indexes. Differential Revision: https://reviews.llvm.org/D59568 llvm-svn: 356601
* Add a __has_extension check for '#pragma clang attribute' as an ↵Erik Pilkington2019-03-202-0/+5
| | | | | | | | external-declaration This was added in r356075. llvm-svn: 356600
* [Sema] Deduplicate some availability checking logicErik Pilkington2019-03-2012-141/+111
| | | | | | | | | | | | | | | Before this commit, we emit unavailable errors for calls to functions during overload resolution, and for references to all other declarations in DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as the DiagnoseAvailabilityOfDecl based checks, as they error on the code from PR40991. This commit fixes this by removing the early checking. llvm.org/PR40991 rdar://48564179 Differential revision: https://reviews.llvm.org/D59394 llvm-svn: 356599
* Recommit "Support attribute used in member funcs of class templates"Rafael Auler2019-03-202-0/+33
| | | | | | | | | | | | | | | | | | | | This diff previously exposed a bug in LLVM's IRLinker, breaking buildbots that tried to self-host LLVM with monolithic LTO. The bug is now in LLVM by D59552 Original commit message: As PR17480 describes, clang does not support the used attribute for member functions of class templates. This means that if the member function is not used, its definition is never instantiated. This patch changes clang to emit the definition if it has the used attribute. Test Plan: Added a testcase Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D56928 llvm-svn: 356598
* [Linker] Fix crash handling appending linkageRafael Auler2019-03-203-5/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When linking two llvm.used arrays, if the resulting merged array ends up with duplicated elements (with the same name) but with different types, the IRLinker was crashing. This was supposed to be legal, as the IRLinker bitcasts elements to match types in these situations. This bug was exposed by D56928 in clang to support attribute used in member functions of class templates. Crash happened when self-hosting with LTO. Since LLVM depends on attribute used to generate code for the dump() method, ubiquitous in the code base, many input bc had a definition of this method referenced in their llvm.used array. Some of these classes got optimized, changing the type of the first parameter (this) in the dump method, leading to a scenario with a pool of valid definitions but some with a different type, triggering this bug. This is a memory bug: ValueMapper depends on (calls) the materializer provided by IRLinker, and this materializer was freely calling RAUW methods whenever a global definition was updated in the temporary merged output file. However, replaceAllUsesWith may or may not destroy constants that use this global. If the linked definition has a type mismatch regarding the new def and the old def, the materializer would bitcast the old type to the new type and the elements of the llvm.used array, which already uses bitcast to i8*, would end up with elements cascading two bitcasts. RAUW would then indirectly call the constantfolder to update the constant to the new ref, which would, instead of updating the constant, destroy it to be able to create a new constant that folds the two bitcasts into one. The problem is that ValueMapper works with pointers to the same constants that may be getting destroyed by RAUW. Obviously, RAUW can update references in the Module to do not use the old destroyed constant, but it can't update ValueMapper's internal pointers to these constants, which are now invalid. The approach here is to move the task of RAUWing old definitions outside of the materializer. Test Plan: Added LIT test case, tested clang self-hosting with D56928 and verified it works Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D59552 llvm-svn: 356597
* [NFC] Fix brace indentation.Alina Sbirlea2019-03-201-1/+1
| | | | llvm-svn: 356596
* [libc++] Use the compiler that CMake found when running lit for ↵Louis Dionne2019-03-201-1/+0
| | | | | | back-deployment tests llvm-svn: 356595
* Resubmit r356511 "[TailCallElim] Add tailcall elimination pass to LTO pipelines"Robert Lougher2019-03-204-0/+31
| | | | | | Failing LLD tests have been fixed in r356593. llvm-svn: 356594
OpenPOWER on IntegriCloud