summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
...
* [LOOPGUARD] Disable loop with multiple loop exiting blocks.Whitney Tsang2019-09-261-0/+120
| | | | | | | | | | | | | | | | | | | | Summary: As discussed in the loop group meeting. With the current definition of loop guard, we should not allow multiple loop exiting blocks. For loops that has multiple loop exiting blocks, we can simply unable to find the loop guard. When getUniqueExitBlock() obtains a vector size not equals to one, that means there is either no exit blocks or there exists more than one unique block the loop exit to. If we don't disallow loop with multiple loop exit blocks, then with our current implementation, there can exist exit blocks don't post dominated by the non pre-header successor of the guard block. Reviewer: reames, Meinersbur, kbarton, etiotto, bmahjour Reviewed By: Meinersbur, kbarton Subscribers: fhahn, hiraditya, llvm-commits Tag: LLVM Differential Revision: https://reviews.llvm.org/D66529 llvm-svn: 373011
* Fix typoMatt Arsenault2019-09-261-2/+2
| | | | llvm-svn: 372988
* [NFC] Add { } to silence compiler warning [-Wmissing-braces].Huihui Zhang2019-09-251-1/+1
| | | | | | | | | llvm-project/llvm/unittests/ADT/ArrayRefTest.cpp:254:25: warning: suggest braces around initialization of subobject [-Wmissing-braces] std::array<int, 5> A1{42, -5, 0, 1000000, -1000000}; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ { } llvm-svn: 372902
* [PatternMatch] Make m_Br more flexible, add matchers for BB values.Florian Hahn2019-09-251-0/+28
| | | | | | | | | | | | | | | | | | | | | Currently m_Br only takes references to BasicBlock*, which limits its flexibility. For example, you have to declare a variable, even if you ignore the result or you have to have additional checks to make sure the matched BB matches an expected one. This patch adds m_BasicBlock and m_SpecificBB matchers, which can be used like the existing matchers for constants or values. I also had a look at the existing uses and updated a few. IMO it makes the code a bit more explicit. Reviewers: spatel, craig.topper, RKSimon, majnemer, lebedev.ri Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D68013 llvm-svn: 372885
* [IR] allow fast-math-flags on phi of FP values (2nd try)Sanjay Patel2019-09-251-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The changes here are based on the corresponding diffs for allowing FMF on 'select': D61917 <https://reviews.llvm.org/D61917> As discussed there, we want to have fast-math-flags be a property of an FP value because the alternative (having them on things like fcmp) leads to logical inconsistency such as: https://bugs.llvm.org/show_bug.cgi?id=38086 The earlier patch for select made almost no practical difference because most unoptimized conditional code begins life as a phi (based on what I see in clang). Similarly, I don't expect this patch to do much on its own either because SimplifyCFG promptly drops the flags when converting to select on a minimal example like: https://bugs.llvm.org/show_bug.cgi?id=39535 But once we have this plumbing in place, we should be able to wire up the FMF propagation and start solving cases like that. The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a regression in a LoopVectorize test. We are intersecting the FMF of any FPMathOperator there, so if a phi is not properly annotated, new math instructions may not be either. Once we fix the propagation in SimplifyCFG, it may be safe to remove that hack. Differential Revision: https://reviews.llvm.org/D67564 llvm-svn: 372878
* Revert [IR] allow fast-math-flags on phi of FP valuesSanjay Patel2019-09-251-5/+2
| | | | | | This reverts r372866 (git commit dec03223a97af0e4dfcb23da55c0f7f8c9b62d00) llvm-svn: 372868
* [IR] allow fast-math-flags on phi of FP valuesSanjay Patel2019-09-251-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The changes here are based on the corresponding diffs for allowing FMF on 'select': D61917 As discussed there, we want to have fast-math-flags be a property of an FP value because the alternative (having them on things like fcmp) leads to logical inconsistency such as: https://bugs.llvm.org/show_bug.cgi?id=38086 The earlier patch for select made almost no practical difference because most unoptimized conditional code begins life as a phi (based on what I see in clang). Similarly, I don't expect this patch to do much on its own either because SimplifyCFG promptly drops the flags when converting to select on a minimal example like: https://bugs.llvm.org/show_bug.cgi?id=39535 But once we have this plumbing in place, we should be able to wire up the FMF propagation and start solving cases like that. The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a regression in a LoopVectorize test. We are intersecting the FMF of any FPMathOperator there, so if a phi is not properly annotated, new math instructions may not be either. Once we fix the propagation in SimplifyCFG, it may be safe to remove that hack. Differential Revision: https://reviews.llvm.org/D67564 llvm-svn: 372866
* [ADT] Add StringMap::insert_or_assignFangrui Song2019-09-251-0/+31
| | | | | | | | | | | | | | Summary: Similar to std::unordered_map::insert_or_assign Reviewers: alexshap, bkramer, dblaikie, lhames Subscribers: jkorous, dexonsmith, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67668 llvm-svn: 372813
* [SCEV] Disable canonical expansion for non-affine addrecs.Artur Pilipenko2019-09-241-0/+182
| | | | | | | | | | Reviewed By: apilipenko Differential Revision: https://reviews.llvm.org/D65276 Patch by Evgeniy Brevnov (ybrevnov@azul.com) llvm-svn: 372789
* [PGO][PGSO] ProfileSummary changes.Hiroshi Yamauchi2019-09-241-0/+42
| | | | | | | | | | (Split of off D67120) ProfileSummary changes for profile guided size optimization. Differential Revision: https://reviews.llvm.org/D67377 llvm-svn: 372783
* [TextAPI] Add New Supported PlatformsCyndy Ishida2019-09-232-0/+54
| | | | | | | | | | | | | | | | Summary: This patch introduces simulators, as well was the restriced zippered and macCatalyst to supported platforms Reviewers: ributzka, steven_wu Reviewed By: ributzka Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67528 llvm-svn: 372618
* [TextAPI] Arch&Platform to TargetCyndy Ishida2019-09-203-64/+130
| | | | | | | | | | | | | | | | | | | | Summary: This is a patch for updating TextAPI/Macho to read in targets as opposed to arch/platform. This is because in previous versions tbd files only supported a single platform but that is no longer the case, so, now its tracked by unique triples. This precedes a seperate patch that will add the TBD-v4 format Reviewers: ributzka, steven_wu, plotfi, compnerd, smeenai Reviewed By: ributzka Subscribers: mgorny, hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67527 llvm-svn: 372396
* [FastISel] Fix insertion of unconditional branches during FastISelDavid Tellenbach2019-09-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | The insertion of an unconditional branch during FastISel can differ depending on building with or without debug information. This happens because FastISel::fastEmitBranch emits an unconditional branch depending on the size of the current basic block without distinguishing between debug and non-debug instructions. This patch fixes this issue by ignoring debug instructions when getting the size of the basic block. Reviewers: aprantl Reviewed By: aprantl Subscribers: ormris, aprantl, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67703 llvm-svn: 372389
* [SVFS] Vector Function ABI demangling.Francesco Petrogalli2019-09-192-0/+440
| | | | | | | | | | | | | | | | This patch implements the demangling functionality as described in the Vector Function ABI. This patch will be used to implement the SearchVectorFunctionSystem (SVFS) as described in the RFC: http://lists.llvm.org/pipermail/llvm-dev/2019-June/133484.html A fuzzer is added to test the demangling utility. Patch by Sumedh Arani <sumedh.arani@arm.com> Differential revision: https://reviews.llvm.org/D66024 llvm-svn: 372343
* Add AutoUpgrade function to add new address space datalayout string to ↵Amy Huang2019-09-182-0/+60
| | | | | | | | | | | | | | | | | | | | | | existing datalayouts. Summary: Add function to AutoUpgrade to change the datalayout of old X86 datalayout strings. This adds "-p270:32:32-p271:32:32-p272:64:64" to X86 datalayouts that are otherwise valid and don't already contain it. This also removes the compatibility changes in https://reviews.llvm.org/D66843. Datalayout change in https://reviews.llvm.org/D64931. Reviewers: rnk, echristo Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67631 llvm-svn: 372267
* Fix compile-time regression caused by rL371928Daniel Sanders2019-09-181-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Also fixup rL371928 for cases that occur on our out-of-tree backend There were still quite a few intermediate APInts and this caused the compile time of MCCodeEmitter for our target to jump from 16s up to ~5m40s. This patch, brings it back down to ~17s by eliminating pretty much all of them using two new APInt functions (extractBitsAsZExtValue(), insertBits() but with a uint64_t). The exact conditions for eliminating them is that the field extracted/inserted must be <=64-bit which is almost always true. Note: The two new APInt API's assume that APInt::WordSize is at least 64-bit because that means they touch at most 2 APInt words. They statically assert that's true. It seems very unlikely that someone is patching it to be smaller so this should be fine. Reviewers: jmolloy Reviewed By: jmolloy Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67686 llvm-svn: 372243
* [Alignment] Add a None() member functionGuillaume Chatelet2019-09-181-1/+4
| | | | | | | | | | | | | | | | | | | Summary: This will allow writing `if(A != llvm::Align::None())` which is clearer than `if(A > llvm::Align(1))` This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67697 llvm-svn: 372207
* Fix buildbots.Greg Clayton2019-09-171-20/+20
| | | | | | MSVC doesn't correctly capture constexpr in lambdas, and other builds warn if you do, others will error out if you do. Avoid lambdas. llvm-svn: 372179
* GSYM: Add the llvm::gsym::Header header class with testsGreg Clayton2019-09-171-0/+102
| | | | | | | | This patch adds the llvm::gsym::Header class which appears at the start of a stand alone GSYM file, or in the first bytes of the GSYM data in a GSYM section within a file. Added encode and decode methods with full error handling and full tests. Differential Revision: https://reviews.llvm.org/D67666 llvm-svn: 372149
* Fix MSVC lambda capture warnings. NFCI.Simon Pilgrim2019-09-171-7/+7
| | | | llvm-svn: 372144
* GSYM: add encoding and decoding to FunctionInfoGreg Clayton2019-09-171-14/+169
| | | | | | | | This patch adds encoding and decoding of the FunctionInfo objects along with full error handling and tests. Full details of the FunctionInfo encoding format appear in the FunctionInfo.h header file. Differential Revision: https://reviews.llvm.org/D67506 llvm-svn: 372135
* [ARM][MVE] Add invalidForTailPredication to TSFlagsSam Parker2019-09-172-0/+183
| | | | | | | | | Set this bit for the MVE reduction instructions to prevent a loop from becoming tail predicated in their presence. Differential Revision: https://reviews.llvm.org/D67444 llvm-svn: 372076
* [Remarks] Allow remarks::Format::YAML to take a string tableFrancis Visoiu Mistrih2019-09-161-35/+65
| | | | | | | It should be allowed to take a string table in case all the strings in the remarks point there, but it shouldn't use it during serialization. llvm-svn: 372042
* [Remarks][NFC] Forward declare ParsedStringTableFrancis Visoiu Mistrih2019-09-131-0/+1
| | | | llvm-svn: 371870
* [yaml2obj/ObjectYAML] - Cleanup the error reporting API, add custom errors ↵George Rimar2019-09-132-8/+54
| | | | | | | | | | | | | | | | | | | | | handlers. This is a continuation of the YAML library error reporting refactoring/improvement and the idea by itself was mentioned in the following thread: https://reviews.llvm.org/D67182?id=218714#inline-603404 This performs a cleanup of all object emitters in the library. It allows using the custom one provided by the caller. One of the nice things is that each tool can now print its tool name, e.g: "yaml2obj: error: <text>" Also, the code became a bit simpler. Differential revision: https://reviews.llvm.org/D67445 llvm-svn: 371865
* [Orc] Address the remaining move-capture FIXMEsBenjamin Kramer2019-09-131-2/+1
| | | | | | | This required spreading unique_function a bit more, which I think is a good thing. llvm-svn: 371843
* Add some missing changes to GSYM that was addressing a gcc compilation error ↵David Blaikie2019-09-111-7/+7
| | | | | | due to a type and variable with the same name llvm-svn: 371681
* Add a LineTable class to GSYM and test it.Greg Clayton2019-09-111-6/+162
| | | | | | | | | | This patch adds the ability to create a gsym::LineTable object, populate it, encode and decode it and test all functionality. The full format of the LineTable encoding is specified in the header file LineTable.h. Differential Revision: https://reviews.llvm.org/D66602 llvm-svn: 371657
* Reland [DWARF] Add a unit test for DWARFUnit::getLength().Igor Kudrin2019-09-101-0/+42
| | | | | | | | | | | This is a follow-up of rL369529, where the return value of DWARFUnit::getLength() was changed from uint32_t to uint64_t. The test checks that a unit header with Length > 4G can be successfully parsed and the value of the Length field is not truncated. Differential Revision: https://reviews.llvm.org/D67276 llvm-svn: 371510
* Revert "[DWARF] Add a unit test for DWARFUnit::getLength()" because it broke ↵Igor Kudrin2019-09-101-42/+0
| | | | | | ASAN bot. llvm-svn: 371505
* [DWARF] Add a unit test for DWARFUnit::getLength().Igor Kudrin2019-09-101-0/+42
| | | | | | | | | | | This is a follow-up of rL369529, where the return value of DWARFUnit::getLength() was changed from uint32_t to uint64_t. The test checks that a unit header with Length > 4G can be successfully parsed and the value of the Length field is not truncated. Differential Revision: https://reviews.llvm.org/D67276 llvm-svn: 371499
* [llvm][ADT][NFC] Add test for makeArrayRef(std::array)Jan Korous2019-09-101-0/+10
| | | | llvm-svn: 371475
* [Remarks] Add parser for bitstream remarksFrancis Visoiu Mistrih2019-09-092-0/+402
| | | | | | | | | | | | | | | | | | | | | | | | | | The bitstream remark serializer landed in r367372. This adds a bitstream remark parser that parser bitstream remark files to llvm::remarks::Remark objects through the RemarkParser interface. A few interesting things to point out: * There are parsing helpers to parse the different types of blocks * The main parsing helper allows us to parse remark metadata and open an external file containing the encoded remarks * This adds a dependency from the Remarks library to the BitstreamReader library * The testing strategy is to create a remark entry through YAML, parse it, serialize it to bitstream, parse that back and compare the objects. * There are close to no tests for malformed bitstream remarks, due to the lack of textual format for the bitstream format. * This adds a new C API for parsing bitstream remarks: LLVMRemarkParserCreateBitstream. * This bumps the REMARKS_API_VERSION to 1. Differential Revision: https://reviews.llvm.org/D67134 llvm-svn: 371429
* Change TargetLibraryInfo analysis passes to always require FunctionTeresa Johnson2019-09-074-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
* [ORC][RPC] Join server thread before checking condition in unit test.Lang Hames2019-09-061-2/+2
| | | | | | Otherwise we have a race on the sent-messages count. llvm-svn: 371263
* [IR] CallBrInst: scan+update arg list when indirect dest list changesNick Desaulniers2019-09-061-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There's an unspoken invariant of callbr that the list of BlockAddress Constants in the "function args" list match the BasicBlocks in the "other labels" list. (This invariant is being added to the LangRef in https://reviews.llvm.org/D67196). When modifying the any of the indirect destinations of a callbr instruction (possible jump targets), we need to update the function arguments if the argument is a BlockAddress whose BasicBlock refers to the indirect destination BasicBlock being replaced. Otherwise, many transforms that modify successors will end up violating that invariant. A recent change to the arm64 Linux kernel exposed this bug, which prevents the kernel from booting. I considered maintaining a mapping from indirect destination BasicBlock to argument operand BlockAddress, but this ends up being a one to potentially many (though usually one) mapping. Also, the list of arguments to a function (or more typically inline assembly) ends up being less than 10. The implementation is significantly simpler to just rescan the full list of arguments. Because of the one to potentially many relationship, the full arg list must be scanned (we can't stop at the first instance). Thanks to the following folks that reported the issue and helped debug it: * Nathan Chancellor * Will Deacon * Andrew Murray * Craig Topper Link: https://bugs.llvm.org/show_bug.cgi?id=43222 Link: https://github.com/ClangBuiltLinux/linux/issues/649 Link: https://lists.infradead.org/pipermail/linux-arm-kernel/2019-September/678330.html Reviewers: craig.topper, chandlerc Reviewed By: craig.topper Subscribers: void, javed.absar, kristof.beyls, hiraditya, llvm-commits, nathanchance, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D67252 llvm-svn: 371262
* [ORC] Add a missing #include atomic.Lang Hames2019-09-061-0/+1
| | | | | | Hopefully this will fix the bot build failures from r371245. llvm-svn: 371255
* GlobalISel: Add G_FMAD instructionMatt Arsenault2019-09-061-0/+4
| | | | llvm-svn: 371254
* [ORC] Make sure RPC channel-send is called in blocking calls and responses.Lang Hames2019-09-062-1/+44
| | | | | | | | | ORC-RPC batches calls by default, and the channel's send method must be called to transfer any buffered calls to the remote. The call to send was missing on responses and blocking calls in the SingleThreadedRPCEndpoint. This patch adds the necessary calls and modifies the RPC unit test to check for them. llvm-svn: 371245
* [FPEnv] Teach the IRBuilder about constrained FPToSI and FPToUI.Kevin P. Neal2019-09-061-0/+11
| | | | | | | | | | | | The IRBuilder doesn't know that the two floating point to integer instructions have constrained equivalents. This patch adds the support by building on the strict FP mode now present in the IRBuilder. Reviewed by: John McCall Approved by: John McCall Differential Revision: https://reviews.llvm.org/D67291 llvm-svn: 371235
* [Remarks] Add support for internalizing a remark in a string tableFrancis Visoiu Mistrih2019-09-061-0/+46
| | | | | | | | | | In order to keep remarks around, we need to make them tied to a string table. Users then can delete the parser and rely on the string table to keep the memory of the strings alive and deduplicated. llvm-svn: 371233
* [MC] Fix undefined behavior in MCInstPrinter::formatHexJonas Devlieghere2019-09-062-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Passing INT64_MIN to MCInstPrinter::formatHex triggers undefined behavior because the negation of -9223372036854775808 cannot be represented in type 'int64_t' (aka 'long long'). This patch puts a workaround in place to just print the hex value directly. A possible alternative involves using a small helper functions that uses (implementation) defined conversions to achieve the desirable value: static int64_t helper(int64_t V) { auto U = static_cast<uint64_t>(V); return V < 0 ? -U : U; } The underlying problem is that MCInstPrinter::formatHex(int64_t) returns a format_object<int64_t> and should really return a format_object<uint64_t>. However, that's not possible because formatImm needs to be able to print both as decimal (where a signed is required) and hex (where we'd prefer to always have an unsigned). format_object<int64_t> formatImm(int64_t Value) const { return PrintImmHex ? formatHex(Value) : formatDec(Value); } Differential revision: https://reviews.llvm.org/D67236 llvm-svn: 371159
* [Remarks] Add comparison operators to the Remark objectFrancis Visoiu Mistrih2019-09-052-0/+78
| | | | | | | | and related structs. This also adds tests for the remarks::Remark object in general. llvm-svn: 371134
* [globalisel][knownbits] Account for missing type constraintsDaniel Sanders2019-09-051-0/+26
| | | | | | | | | | | | | Now that we look through copies, it's possible to visit registers that have a register class constraint but not a type constraint. Avoid looking through copies when this occurs as the SrcReg won't be able to determine it's bit width or any known bits. Along the same lines, if the initial query is on a register that doesn't have a type constraint then the result is a default-constructed KnownBits, that is, a 1-bit fully-unknown value. llvm-svn: 371116
* [globalisel][knownbits] Correct a typo that prevented a test working as intendedDaniel Sanders2019-09-051-1/+1
| | | | llvm-svn: 371115
* [Remarks] Don't serialize metadata if a string table is not usedFrancis Visoiu Mistrih2019-09-051-10/+60
| | | | | | | For YAML remarks with no string table, the mode should not affect the output. llvm-svn: 371106
* [Support] Add writeFileAtomically() to FileUtilitiesJan Korous2019-09-052-0/+53
| | | | | | Differential Revision: https://reviews.llvm.org/D66859 llvm-svn: 371103
* [globalisel] Support trivial COPY in GISelKnownBitsDaniel Sanders2019-09-041-0/+6
| | | | | | | | | | | | | | Summary: Allow GISelKnownBits to look through the trivial case of TargetOpcode::COPY Reviewers: aditya_nandakumar Subscribers: rovka, hiraditya, volkan, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67131 llvm-svn: 370955
* Add encode and decode methods to InlineInfo and document encoding format to ↵Greg Clayton2019-09-041-0/+136
| | | | | | | | | | the GSYM file format. This patch adds the ability to encode and decode InlineInfo objects and adds test coverage. Error handling is introduced in the encoding and decoding which will be used from here on out for remaining patches. Differential Revision: https://reviews.llvm.org/D66600 llvm-svn: 370936
* Skip MCJIT unit tests if LLVM is not configured for native compilationDavid Blaikie2019-09-031-1/+7
| | | | | | | | Patch by Sergej Jaskiewicz! Differential Revision: D67089 llvm-svn: 370812
OpenPOWER on IntegriCloud