summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [ARM] Refactor handling of IT mask operands.Simon Tatham2019-06-136-64/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During assembly, the mask operand to an IT instruction (storing the sequence of T/E for 'Then' and 'Else') is parsed out of the mnemonic into a representation that encodes 'Then' and 'Else' in the same way regardless of the condition code. At some point during encoding it has to be converted into the instruction encoding used in the architecture, in which the mask encodes a sequence of replacement low-order bits for the condition code, so that which bit value means 'then' and which 'else' depends on whether the original condition code had its low bit set. Previously, that transformation was done by processInstruction(), half way through assembly. So an MCOperand storing an IT mask would sometimes store it in one format, and sometimes in the other, depending on where in the assembly pipeline you were. You can see this in diagnostics from `llvm-mc -debug -triple=thumbv8a -show-inst`, for example: if you give it an instruction such as `itete eq`, you'd see an `<MCOperand Imm:5>` in a diagnostic become `<MCOperand Imm:11>` in the final output. Having the same data structure store values with time-dependent semantics is confusing already, and it will get more confusing when we introduce the MVE VPT instruction which reuses the Then/Else bitmask idea in a different context. So I'm refactoring: now, all `ARMOperand` and `MCOperand` representations of an IT mask work exactly the same way, namely, 0 means 'Then' and 1 means 'Else', regardless of what original predicate is being referred to. The architectural encoding of IT that depends on the original condition is now constructed at the point when we turn the `MCOperand` into the final instruction bit pattern, and decoded similarly in the disassembler. The previous condition-independent parse-time format used 0 for Else and 1 for Then. I've taken the opportunity to flip the sense of it while I'm changing all of this anyway, because it seems to me more natural to use 0 for 'leave the starting condition unchanged' and 1 for 'invert it', as if those bits were an XOR mask. Reviewers: ostannard Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63219 llvm-svn: 363244
* [llvm-objcopy] Implement IHEX readerEugene Leviant2019-06-137-49/+520
| | | | | | | This is the final part of IHEX format support in llvm-objcopy Differential revision: https://reviews.llvm.org/D62583 llvm-svn: 363243
* [OpenCL] Move OpenCLBuiltins.td and remove unused includeSven van Haastregt2019-06-134-7/+8
| | | | | | | | Patch by Pierre Gondois. Differential revision: https://reviews.llvm.org/D62849 llvm-svn: 363242
* [WebAssembly] Modernize include path handlingSam Clegg2019-06-133-7/+44
| | | | | | | | | | Move include path construction from InitHeaderSearch::AddDefaultIncludePaths in the Driver which appears to be the more modern/correct way of doing things. Differential Revision: https://reviews.llvm.org/D63030 llvm-svn: 363241
* Improve reduction intrinsics by overloading result value.Sander de Smalen2019-06-1362-5258/+5283
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch uses the mechanism from D62995 to strengthen the definitions of the reduction intrinsics by letting the scalar result/accumulator type be overloaded from the vector element type. For example: ; The LLVM LangRef specifies that the scalar result must equal the ; vector element type, but this is not checked/enforced by LLVM. declare i32 @llvm.experimental.vector.reduce.or.i32.v4i32(<4 x i32> %a) This patch changes that into: declare i32 @llvm.experimental.vector.reduce.or.v4i32(<4 x i32> %a) Which has the type-constraint more explicit and causes LLVM to check the result type with the vector element type. Reviewers: RKSimon, arsenm, rnk, greened, aemerson Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D62996 llvm-svn: 363240
* Revert [llvm-ar][test] Add to MRI test coverageOwen Reynolds2019-06-135-157/+0
| | | | | | | | This reverts 363232 due to mru-utf8.test buildbot test failure Differential Revision: https://reviews.llvm.org/D63197 llvm-svn: 363239
* [clang-scan-deps] Fix -DBUILD_SHARED_LIBS=ON buildSam Clegg2019-06-131-0/+1
| | | | | | | | The -DBUILD_SHARED_LIBS=ON build was broken in rL363204 Differential Revision: https://reviews.llvm.org/D63245 llvm-svn: 363238
* [clangd] Treat lambdas as functions when preparing hover responseKadir Cetinkaya2019-06-132-19/+108
| | | | | | | | | | | | Reviewers: sammccall, ilya-biryukov Subscribers: MaskRay, jkorous, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62814 llvm-svn: 363237
* [ELF] Loosen the condition that changes absolute relocation types to ↵Fangrui Song2019-06-131-1/+7
| | | | | | | | relative relocations for ARM and PPC64 Try fixing build bots after D63121 llvm-svn: 363236
* [NFC] Simplify Call querySam Parker2019-06-131-1/+1
| | | | | | Use getIntrinsicID() directly from IntrinsicInst. llvm-svn: 363235
* [ARM][TTI] Scan for existing loop intrinsicsSam Parker2019-06-132-5/+101
| | | | | | | | | TTI should report that it's not profitable to generate a hardware loop if it, or one of its child loops, has already been converted. Differential Revision: https://reviews.llvm.org/D63212 llvm-svn: 363234
* [IntrinsicEmitter] Extend argument overloading with forward references.Sander de Smalen2019-06-136-73/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the mechanism to overload intrinsic arguments by using either backward or forward references to the overloadable arguments. In for example: def int_something : Intrinsic<[LLVMPointerToElt<0>], [llvm_anyvector_ty], []>; LLVMPointerToElt<0> is a forward reference to the overloadable operand of type 'llvm_anyvector_ty' and would allow intrinsics such as: declare i32* @llvm.something.v4i32(<4 x i32>); declare i64* @llvm.something.v2i64(<2 x i64>); where the result pointer type is deduced from the element type of the first argument. If the returned pointer is not a pointer to the element type, LLVM will give an error: Intrinsic has incorrect return type! i64* (<4 x i32>)* @llvm.something.v4i32 Reviewers: RKSimon, arsenm, rnk, greened Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D62995 llvm-svn: 363233
* [llvm-ar][test] Add to MRI test coverageOwen Reynolds2019-06-135-0/+157
| | | | | | | | This change adds tests to cover existing MRI script functionality. Differential Revision: https://reviews.llvm.org/D63197 llvm-svn: 363232
* [X86] Correct instruction operands in evex-to-vex-compress.mir to be closer ↵Craig Topper2019-06-131-1777/+1777
| | | | | | | | | | | | | to real instructions. $noreg was being used way more than it should have. We also had xmm registers in addressing modes. Mostly found by hacking the machine verifier to do some stricter checking that happened to work for this test, but not sure if generally applicable for other tests or other targets. llvm-svn: 363231
* clang-format extension: Widen the supported versions rangeHans Wennborg2019-06-131-1/+1
| | | | | | | | So that it covers also the latest VS 2019 version. By Antonio Maiorano! llvm-svn: 363230
* [SimplifyCFG] reverting preliminary Switch patches againShawn Landden2019-06-1320-2593/+1435
| | | | | | | | | This reverts 363226 and 363227, both NFC intended I swear I fixed the test case that is failing, and ran the tests, but I will look into it again. llvm-svn: 363229
* [Reproducers] Remove call to lldb_private::GetVersion()Jonas Devlieghere2019-06-131-2/+1
| | | | | | | | Utility doesn't link against lldbBase so we cannot call GetVersion in keep. I already added a string member m_version to deal with that, but the call was still there. llvm-svn: 363228
* [SimpligyCFG] NFC intended, remove GCD that was only used for powers of twoShawn Landden2019-06-131-13/+11
| | | | | | | | | | | | and replace with an equilivent countTrailingZeros. GCD is much more expensive than this, with repeated division. This depends on D60823 Differential Revision: https://reviews.llvm.org/D61151 llvm-svn: 363227
* [SimplifyCFG] NFC, update Switch tests to better examine successive patchesShawn Landden2019-06-1319-1422/+2582
| | | | | | | | | | | Also add baseline tests to show effect of later patches. There were a couple of regressions here that were never caught, but my patch set that this is a preparation to will fix them. Differential Revision: https://reviews.llvm.org/D61150 llvm-svn: 363226
* [Reproducers] Include lldb version in the reproducer rootJonas Devlieghere2019-06-134-5/+43
| | | | | | | | | | | Generally, reproducers are rev-locked to the version of LLDB, so it's valuable to have the LLDB version in the reproducer. For now I just want the information to be present, without enforcing it, but I envision emitting a warning during replay in the future. Differential revision: https://reviews.llvm.org/D63229 llvm-svn: 363225
* [X86] Add tests for some the special cases in EVEX to VEX to the ↵Craig Topper2019-06-131-1/+137
| | | | | | evex-to-vex-compress.mir test. llvm-svn: 363224
* [SimplifyCFG] revert the last commit.Shawn Landden2019-06-1316-2469/+1308
| | | | | | I ran ALL the test suite locally, so I will look into this... llvm-svn: 363223
* [SimplifyCFG] NFC, update Switch tests to HEAD so I canShawn Landden2019-06-1316-1308/+2469
| | | | | | | | | | see if my changes change anything Also add baseline tests to show effect of later patches. Differential Revision: https://reviews.llvm.org/D61150 llvm-svn: 363222
* X86: Clean up pass initializationTom Stellard2019-06-1314-43/+21
| | | | | | | | | | | | | | | | | | | | Summary: - Remove redundant initializations from pass constructors that were already being initialized by LLVMInitializeX86Target(). - Add initialization function for the FPS pass. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63218 llvm-svn: 363221
* Revert r361811: 'Re-commit r357452 (take 2): "SimplifyCFG ↵David L. Jones2019-06-139-128/+84
| | | | | | | | | | | | | | | | SinkCommonCodeFromPredecessors ...' We have observed some failures with internal builds with this revision. - Performance regressions: - llvm's SingleSource/Misc evalloop shows performance regressions (although these may be red herrings). - Benchmarks for Abseil's SwissTable. - Correctness: - Failures for particular libicu tests when building the Google AppEngine SDK (for PHP). hwennborg has already been notified, and is aware of reproducer failures. llvm-svn: 363220
* Make GCC in C++03 UnsupportedEric Fiselier2019-06-132-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch make G++03 explicitly unsupported with libc++, as discussed on the mailing lists. Below is the rational for this decision. ---------------------------------------------------------------------------------------------------- libc++ claims to support GCC with C++03 ("G++03"), and this is a problem for our users. Our C++03 users are all using Clang. They must be. Less than 9% of the C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work. Attempting to support G++03 impacts our QoI considerably. Unlike Clang, G++03 offers almost no C++11 extensions. If we could remove all the fallbacks for G++03, it would mean libc++ could:: * Improve Correctness: Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists to admit for deviant semantics. * Achieve ABI stability between C++03 and C++11 Differences between our C++03 and C++Rest branches contain ABI bugs. For example `std::nullptr_t` and `std::function::operator()(...)` are currently incompatible between C++11 and C++03, but could be fixed. * Decrease Compile Times and Memory Usage: Writing efficient SFINAE requires C++11. Using alias templates, libc++ could reduce the number of instantiations it produces substantially. * Decrease Binary Size Similar to the last point, G++03 forces metaprogramming techniques that emit more debug information [3] [4]. Compared to libstdc++, debug information size increases of +10% are not uncommon. Reviewers: ldionne, mclow.lists, EricWF Reviewed By: ldionne, EricWF Subscribers: zoecarver, aprantl, dexonsmith, arphaman, libcxx-commits, #libc Differential Revision: https://reviews.llvm.org/D63154 llvm-svn: 363219
* [SLP] Update propagate_ir_flags.ll test to check that we do retain the ↵Dinar Temirbulatov2019-06-131-0/+36
| | | | | | common subset, NFC. llvm-svn: 363218
* [Tests] Highlight impact of multiple exit LFTR (D62625) as requested by reviewerPhilip Reames2019-06-121-0/+158
| | | | llvm-svn: 363217
* [ScopBuilder] Move addInvariantLoads to ScopBuilder. NFC.Michael Kruse2019-06-124-180/+188
| | | | | | | | | | | | | | | | | | | Moved addInvariantLoads and functions listed below to ScopBuilder: isAParameter canAlwaysBeHoisted These functions were referenced only by getNonHoistableCtx. Moved CLI parameter PollyAllowDereferenceOfAllFunctionParams to ScopBuilder. Added iterator range through InvariantEquivClasses. Patch by Dominik Adamski <adamski.dominik@gmail.com> Differential Revision: https://reviews.llvm.org/D63172 llvm-svn: 363216
* [NFC][CodeGen] Add unary FNeg tests to X86/avx512-intrinsics-fast-isel.llCameron McInally2019-06-121-0/+657
| | | | | | Patch 1 of n. llvm-svn: 363215
* [ScopBuilder] Move getNonHoistableCtx to ScopBuilder. NFC.Michael Kruse2019-06-124-136/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | This review is based on review: https://reviews.llvm.org/D62925 . It is part of moving hoistInvariantLoads function and all functions referenced only by hoistInvariantLoads to ScopBuilder. Moved getNonHoistableCtx and functions listed below to ScopBuilder: isRequiredInvariantLoad hasNonHoistableBasePtrInScop isAccessRangeTooComplex These functions were referenced only by getNonHoistableCtx. MaxDimensionsInAccessRange and MaxDisjunctsInDomain constant is marked as extern and it is added to polly namespace. It is used by Scop and ScopBuilder classes. MaxDimensionsInAccessRange constant moved to ScopBuilder. It is not used outside ScopBuilder. Patch by Dominik Adamski <adamski.dominik@gmail.com> Differential Revision: https://reviews.llvm.org/D63066 llvm-svn: 363214
* [lld] Fix type server merging with PDBs without IPI streamReid Kleckner2019-06-124-13/+39
| | | | | | | | | | | | | | | PDBs may not necessarily contain an IPI stream. Handle this case gracefully. The test case was verified to work with MS link.exe. Patch by Vladimir Panteleev, with a small simplification Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D63178 llvm-svn: 363213
* [lld] Allow unrecognized signatures in debug sectionsReid Kleckner2019-06-122-4/+33
| | | | | | | | | | | | | | | | | | An unrecognized signature (magic) at the beginning of a debug section should not be a fatal error; it only means that the debug information is in a format that is not supported by LLD. This can be due to it being in CodeView versions 3 or earlier. These can occur in old import libraries from legacy SDKs. The test case was verified to work with MS link.exe. Patch by Vladimir Panteleev! Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D63177 llvm-svn: 363212
* [Reproducers] Simplify providers with nested Info struct (NFC)Jonas Devlieghere2019-06-128-52/+41
| | | | | | | | | This replaces the `info` typedef with a nested struct named Info. This means we now have FooProvider and FooProvider::Info, instead of two related but separate classes FooProvider and FooInfo. This change is mostly cosmetic. llvm-svn: 363211
* [llvm] Expose DWARFDebugLine::LineTable::getFileNameEntryMircea Trofin2019-06-121-2/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: This is useful for scenarios where Prologue was directly used and DWARF 5 awareness is required. The current alternative would be to either duplicate the logic in getFileNameEntry, or to use getFileNameByIndex. The latter isn't quite an in-place replacement - it performs some processing, and it produces a string instead of a StringRef, meaning the caller needs to handle its lifetime. Reviewers: tamur, dblaikie, JDevlieghere Reviewed By: tamur, JDevlieghere Subscribers: aprantl, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D63228 llvm-svn: 363210
* [libcxx] XFAIL set/multiset CTAD tests on Apple Clang 10Louis Dionne2019-06-122-2/+2
| | | | llvm-svn: 363209
* [clang-scan-deps] Include <mutex> in ClangScanDeps.cpp to ensure itAlex Lorenz2019-06-121-0/+1
| | | | | | builds on all platforms llvm-svn: 363208
* NFC, Update the ClangScanDeps.cpp file's license commentAlex Lorenz2019-06-121-5/+4
| | | | | | | The file ClangScanDeps.cpp from r363204 had the old outdated LLVM license comment at the top of the file that I committed by accident. llvm-svn: 363207
* Re-land r363103 ("When reading ObjC class table, use new SPI if it is avail")Jason Molenda2019-06-121-4/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | with a call to snprintf() to find the size of the formatted string, malloc memory, then snprintf again to format it into the buffer, instead of calling asprintf. Orig commit msg: When reading ObjC class table, use new SPI if it is avail In the latest OS betas, the objc runtime has a special interface for the debugger, class_getNameRaw(), instead of the existing class_getName(), which will return class names in their raw, unmangled (in the case of swift) form. When lldb can access the unmangled names of classes, it won't need to fetch them out of the inferior process after we run our "get the objc class table" expression. If the new interface is absent (debugging a process on an older target), lldb will fall back to class_getName and reading any class names that it got back in demangled form, at a bit of a performance cost on the first expression. <rdar://problem/50688054> llvm-svn: 363206
* NFC, fixup indentation in CMakeLists.txt from r363204 as requestedAlex Lorenz2019-06-121-3/+3
| | | | | | | | | in the review. I missed that review comment from https://reviews.llvm.org/D60233 in the original commit. llvm-svn: 363205
* [clang-scan-deps] initial outline of the tool that runs preprocessor to findAlex Lorenz2019-06-128-0/+289
| | | | | | | | | | | | | | | | | | | | | | | dependencies over a JSON compilation database This commit introduces an outline for the clang-scan-deps tool that will be used to implement fast dependency discovery phase using implicit modules for explicit module builds. The initial version of the tool works by computing non-modular header dependencies for files in the compilation database without any optimizations (i.e. without source minimization from r362459). The tool spawns a number of worker threads to run the clang compiler workers in parallel. The immediate goal for clang-scan-deps is to create a ClangScanDeps library which will be used to build up this tool to use the source minimization and caching multi-threaded filesystem to implement the optimized non-incremental dependency scanning phase for a non-modular build. This will allow us to do benchmarks and comparisons for performance that the minimization and caching give us Differential Revision: https://reviews.llvm.org/D60233 llvm-svn: 363204
* [x86] add tests for vector shifts; NFCSanjay Patel2019-06-123-0/+642
| | | | llvm-svn: 363203
* Skip failing test on older versions of clang.Adrian Prantl2019-06-121-0/+1
| | | | llvm-svn: 363202
* Sanitize llvm-extract -help outputSerge Guelton2019-06-121-37/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Filter out irrelevant options New output: OVERVIEW: llvm extractor USAGE: llvm-extract [options] <input bitcode file> OPTIONS: Generic Options: --help - Display available options (--help-hidden for more) --help-list - Display list of available options (--help-list-hidden for more) --version - Display the version of this program llvm-extract Options: --alias=<alias> - Specify alias to extract --bb=<function:bb> - Specify <function, basic block> pairs to extract --delete - Delete specified Globals from Module -f - Enable binary output on terminals --func=<function> - Specify function to extract --glob=<global> - Specify global to extract -o=<filename> - Specify output filename --ralias=<ralias> - Specify alias(es) to extract using a regular expression --recursive - Recursively extract all called functions --rfunc=<rfunction> - Specify function(s) to extract using a regular expression --rglob=<rglobal> - Specify global(s) to extract using a regular expression Differential Revision: https://reviews.llvm.org/D62511 llvm-svn: 363201
* [NFC][CodeGen] Add unary FNeg tests to X86/avx512vl-intrinsics-fast-isel.llCameron McInally2019-06-121-0/+71
| | | | | | Patch 3 of 3 for X86/avx512vl-intrinsics-fast-isel.ll llvm-svn: 363200
* [test] Reinstate the assignment to the diagnostic log in the unittestAlex Lorenz2019-06-121-0/+4
| | | | | | | | | | from r363009 The diagnostic log is now set to "-" which forces it to use STDERR instead of the filesystem. A new comment is added to explain why the assignment is needed in the test. llvm-svn: 363199
* [llvm-readobj] Fix output interleaving issue caused by using multiple ↵Jordan Rupprecht2019-06-125-14/+61
| | | | | | | | | | | | | | | | | | | | | | | | streams at the same time. Summary: Use llvm::fouts() as the default stream for outputing. No new stream should be constructed to output at the same time. https://bugs.llvm.org/show_bug.cgi?id=42140 Reviewers: jhenderson, grimar, MaskRay, phosek, rupprecht Reviewed By: rupprecht Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63115 Patch by Yuanfang Chen! llvm-svn: 363198
* [libcxx] XFAIL some CTAD tests on AppleClang 10Louis Dionne2019-06-122-2/+2
| | | | | | | AppleClang 10 doesn't contain some changes that are required for this test to give the right error message. llvm-svn: 363197
* [IndVars] Extend diagnostic -replexitval flag w/ability to bypass hard use ↵Philip Reames2019-06-121-2/+5
| | | | | | | hueristic Note: This does mean that "always" is now more powerful than it was. llvm-svn: 363196
* Add comment to r363191 code as requested in code reviewReid Kleckner2019-06-121-2/+5
| | | | llvm-svn: 363195
OpenPOWER on IntegriCloud