summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
...
* [ConstantRange] [a, b) udiv a full range is [0, umax(b)).Florian Hahn2019-04-251-0/+10
| | | | | | | | | | Reviewers: nikic, spatel, efriedma Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D60536 llvm-svn: 359180
* [Testing] Move clangd::Annotations to llvm testing supportIlya Biryukov2019-04-252-0/+113
| | | | | | | | | | | | | | | | | | | | | | | Summary: Annotations allow writing nice-looking unit test code when one needs access to locations from the source code, e.g. running code completion at particular offsets in a file. See comments in Annotations.cpp for more details on the API. Also got rid of a duplicate annotations parsing code in clang's code complete tests. Reviewers: gribozavr, sammccall Reviewed By: gribozavr Subscribers: mgorny, hiraditya, ioeric, MaskRay, jkorous, arphaman, kadircet, jdoerfert, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D59814 llvm-svn: 359179
* [Support] Add a GTest matcher for Optional<T>Ilya Biryukov2019-04-252-0/+26
| | | | | | | | | | | | | | Reviewers: sammccall Reviewed By: sammccall Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61071 llvm-svn: 359174
* Add optional arg to profile count getters to filterXinliang David Li2019-04-241-1/+1
| | | | | | | | synthetic profile count. Differential Revision: http://reviews.llvm.org/D61025 llvm-svn: 359131
* Revert [AliasAnalysis] AAResults preserves AAManager.Alina Sbirlea2019-04-241-0/+1
| | | | | | Triggers use-after-free. llvm-svn: 359055
* [Remarks] Add string deduplication using a string tableFrancis Visoiu Mistrih2019-04-243-0/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add support for uniquing strings in the remark streamer and emitting the string table in the remarks section. * Add parsing support for the string table in the RemarkParser. From this remark: ``` --- !Missed Pass: inline Name: NoDefinition DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 7, Column: 3 } Function: printArgsNoRet Args: - Callee: printf - String: ' will not be inlined into ' - Caller: printArgsNoRet DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 6, Column: 0 } - String: ' because its definition is unavailable' ... ``` to: ``` --- !Missed Pass: 0 Name: 1 DebugLoc: { File: 3, Line: 7, Column: 3 } Function: 2 Args: - Callee: 4 - String: 5 - Caller: 2 DebugLoc: { File: 3, Line: 6, Column: 0 } - String: 6 ... ``` And the string table in the .remarks/__remarks section containing: ``` inline\0NoDefinition\0printArgsNoRet\0 test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c\0printf\0 will not be inlined into \0 because its definition is unavailable\0 ``` This is mostly supposed to be used for testing purposes, but it gives us a 2x reduction in the remark size, and is an incremental change for the updates to the remarks file format. Differential Revision: https://reviews.llvm.org/D60227 llvm-svn: 359050
* [ConstantRange] Add urem supportNikita Popov2019-04-231-8/+54
| | | | | | | | | | | | | Add urem support to ConstantRange, so we can handle in in LVI. This is an approximate implementation that tries to capture the most useful conditions: If the LHS is always strictly smaller than the RHS, then the urem is a no-op and the result is the same as the LHS range. Otherwise the lower bound is zero and the upper bound is min(LHSMax, RHSMax - 1). Differential Revision: https://reviews.llvm.org/D60952 llvm-svn: 359019
* [ConstantRangeTest] Move helper methods; NFCNikita Popov2019-04-231-54/+54
| | | | | | | Move Test(Unsigned|Signed)BinOpExhaustive() towards the top of the file, so they're easier to reuse. llvm-svn: 359018
* [AliasAnalysis] AAResults preserves AAManager.Alina Sbirlea2019-04-231-1/+0
| | | | | | | | | | | | | | | | Summary: AAResults should not invalidate AAManager. Update tests. Reviewers: chandlerc Subscribers: mehdi_amini, jlebar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60914 llvm-svn: 359014
* [APSInt][OpenMP] Fix isNegative, etc. for unsigned typesJoel E. Denny2019-04-231-0/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch, APSInt inherits APInt::isNegative, which merely checks the sign bit without regard to whether the type is actually signed. isNonNegative and isStrictlyPositive call isNegative and so are also affected. This patch adjusts APSInt to override isNegative, isNonNegative, and isStrictlyPositive with implementations that consider whether the type is signed. A large set of Clang OpenMP tests are affected. Without this patch, these tests assume that `true` is not a valid argument for clauses like `collapse`. Indeed, `true` fails APInt::isStrictlyPositive but not APSInt::isStrictlyPositive. This patch adjusts those tests to assume `true` should be accepted. This patch also adds tests revealing various other similar fixes due to APSInt::isNegative calls in Clang's ExprConstant.cpp and SemaExpr.cpp: `++` and `--` overflow in `constexpr`, evaluated object size based on `alloc_size`, `<<` and `>>` shift count validation, and OpenMP array section validation. Reviewed By: lebedev.ri, ABataev, hfinkel Differential Revision: https://reviews.llvm.org/D59712 llvm-svn: 359012
* [Support] unflake TempFileCollisions testBob Haarman2019-04-221-4/+12
| | | | | | | | | | | | | | | | | | | | | | Summary: This test was added to verify that createUniqueEntity() does not enter an infinite loop when all possible names are taken. However, it also checked that all possible names are generated, which is flaky (because the names are generated randomly). This change increases the number of attempts we make to make flakes exceedingly unlikely (3.88e-62). Reviewers: fedor.sergeev, rsmith Reviewed By: fedor.sergeev Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D56336 llvm-svn: 358914
* Revert "[ConstantRange] Rename make{Guaranteed -> Exact}NoWrapRegion() NFC"Nikita Popov2019-04-221-40/+40
| | | | | | | | | | This reverts commit 7bf4d7c07f2fac862ef34c82ad0fef6513452445. After thinking about this more, this isn't right, the range is not exact in the same sense as makeExactICmpRegion(). This needs a separate function. llvm-svn: 358876
* [ConstantRange] Rename make{Guaranteed -> Exact}NoWrapRegion() NFCNikita Popov2019-04-221-40/+40
| | | | | | | | Following D60632 makeGuaranteedNoWrapRegion() always returns an exact nowrap region. Rename the function accordingly. This is in line with the naming of makeExactICmpRegion(). llvm-svn: 358875
* [JITLink] Remove a lot of reduntant 'JITLink_' prefixes. NFC.Lang Hames2019-04-222-3/+3
| | | | llvm-svn: 358869
* [ConstantRange] Add saturating add/sub methodsNikita Popov2019-04-211-0/+94
| | | | | | | | | | | | | | | | Add support for uadd_sat and friends to ConstantRange, so we can handle uadd.sat and friends in LVI. The implementation is forwarding to the corresponding APInt methods with appropriate bounds. One thing worth pointing out here is that the handling of wrapping ranges is not maximally accurate. A simple example is that adding 0 to a wrapped range will return a full range, rather than the original wrapped range. The tests also only check that the non-wrapping envelope is correct and minimal. Differential Revision: https://reviews.llvm.org/D60946 llvm-svn: 358855
* [JITLink] Add dependency on MCParser to unit test after rL358818Fangrui Song2019-04-211-0/+1
| | | | | | This is required by -DBUILD_SHARED_LIBS=on builds for createMCAsmParser. llvm-svn: 358842
* [JITLink] Add dependencies on MCDissassembler and Target to unit test.Lang Hames2019-04-211-0/+2
| | | | llvm-svn: 358836
* [JITLink] Add check to JITLink unit test to bail out for unsupported targets.Lang Hames2019-04-203-19/+52
| | | | | | | This should prevent spurious JITLink unit test failures for builds that do not support the target(s) required by the tests. llvm-svn: 358825
* Initial implementation of JITLink - A replacement for RuntimeDyld.Lang Hames2019-04-205-0/+668
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: JITLink is a jit-linker that performs the same high-level task as RuntimeDyld: it parses relocatable object files and makes their contents runnable in a target process. JITLink aims to improve on RuntimeDyld in several ways: (1) A clear design intended to maximize code-sharing while minimizing coupling. RuntimeDyld has been developed in an ad-hoc fashion for a number of years and this had led to intermingling of code for multiple architectures (e.g. in RuntimeDyldELF::processRelocationRef) in a way that makes the code more difficult to read, reason about, extend. JITLink is designed to isolate format and architecture specific code, while still sharing generic code. (2) Support for native code models. RuntimeDyld required the use of large code models (where calls to external functions are made indirectly via registers) for many of platforms due to its restrictive model for stub generation (one "stub" per symbol). JITLink allows arbitrary mutation of the atom graph, allowing both GOT and PLT atoms to be added naturally. (3) Native support for asynchronous linking. JITLink uses asynchronous calls for symbol resolution and finalization: these callbacks are passed a continuation function that they must call to complete the linker's work. This allows for cleaner interoperation with the new concurrent ORC JIT APIs, while still being easily implementable in synchronous style if asynchrony is not needed. To maximise sharing, the design has a hierarchy of common code: (1) Generic atom-graph data structure and algorithms (e.g. dead stripping and | memory allocation) that are intended to be shared by all architectures. | + -- (2) Shared per-format code that utilizes (1), e.g. Generic MachO to | atom-graph parsing. | + -- (3) Architecture specific code that uses (1) and (2). E.g. JITLinkerMachO_x86_64, which adds x86-64 specific relocation support to (2) to build and patch up the atom graph. To support asynchronous symbol resolution and finalization, the callbacks for these operations take continuations as arguments: using JITLinkAsyncLookupContinuation = std::function<void(Expected<AsyncLookupResult> LR)>; using JITLinkAsyncLookupFunction = std::function<void(const DenseSet<StringRef> &Symbols, JITLinkAsyncLookupContinuation LookupContinuation)>; using FinalizeContinuation = std::function<void(Error)>; virtual void finalizeAsync(FinalizeContinuation OnFinalize); In addition to its headline features, JITLink also makes other improvements: - Dead stripping support: symbols that are not used (e.g. redundant ODR definitions) are discarded, and take up no memory in the target process (In contrast, RuntimeDyld supported pointer equality for weak definitions, but the redundant definitions stayed resident in memory). - Improved exception handling support. JITLink provides a much more extensive eh-frame parser than RuntimeDyld, and is able to correctly fix up many eh-frame sections that RuntimeDyld currently (silently) fails on. - More extensive validation and error handling throughout. This initial patch supports linking MachO/x86-64 only. Work on support for other architectures and formats will happen in-tree. Differential Revision: https://reviews.llvm.org/D58704 llvm-svn: 358818
* [ADT] Avoid warning in bsearch testcaseSam McCall2019-04-201-3/+3
| | | | llvm-svn: 358811
* [NewPassManager] Adding pass tuning options: loop vectorize.Alina Sbirlea2019-04-191-1/+2
| | | | | | | | | | | | | | | | Summary: Trying to add the plumbing necessary to add tuning options to the new pass manager. Testing with the flags for loop vectorize. Reviewers: chandlerc Subscribers: sanjoy, mehdi_amini, jlebar, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59723 llvm-svn: 358763
* [APInt] Optimize umul_ovFangrui Song2019-04-191-0/+36
| | | | | | | | | | | | | Change two costly udiv() calls to lshr(1)*RHS + left-shift + plus On one 64-bit umul_ov benchmark, I measured an obvious improvement: 12.8129s -> 3.6257s Note, there may be some value to special case 64-bit (the most common case) with __builtin_umulll_overflow(). Differential Revision: https://reviews.llvm.org/D60669 llvm-svn: 358730
* Test commit access [NFC]Cullen Rhodes2019-04-181-1/+1
| | | | | | Remove a trailing space llvm-svn: 358648
* [Support] Add LEB128 support to BinaryStreamReader/Writer.Lang Hames2019-04-171-0/+71
| | | | | | | | | | | | | | | | | | | Summary: This patch adds support for ULEB128 and SLEB128 encoding and decoding to BinaryStreamWriter and BinaryStreamReader respectively. Support for ULEB128/SLEB128 will be used for eh-frame parsing in the JITLink library currently under development (see https://reviews.llvm.org/D58704). Reviewers: zturner, dblaikie Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60810 llvm-svn: 358584
* [ADT] llvm::bsearch, binary search for mere mortalsSam McCall2019-04-161-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add to STLExtras a binary search function with a simple mental model: You provide a range and a predicate which is true above a certain point. bsearch() tells you that point. Overloads are provided for integers, iterators, and containers. This is more suitable than std:: alternatives in many cases: - std::binary_search only indicates presence/absence - upper_bound/lower_bound give you the opportunity to pick the wrong one - all of the options have confusing names and definitions when your predicate doesn't have simple "less than" semantics - all of the options require iterators - we plumb around a useless `value` parameter that should be a lambda capture The API is inspired by Go's standard library, but we add an extra parameter as well as some overloads and templates to show how clever C++ is. Reviewers: ilya-biryukov, gribozavr Subscribers: dexonsmith, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60779 llvm-svn: 358540
* Reapply [Support] Fix recursive response file expansion guardShoaib Meenai2019-04-161-0/+37
| | | | | | | | | | | | | | | | | | | | | The test in the dependent revision has been fixed for Windows. Original commit message: Response file expansion limits the amount of expansion to prevent potential infinite recursion. However, the current logic assumes that any argument beginning with @ is a response file, which is not true for e.g. `-Xlinker -rpath -Xlinker @executable_path/../lib` on Darwin. Having too many of these non-response file arguments beginning with @ prevents actual response files from being expanded. Instead, limit based on the number of successful response file expansions, which should still prevent infinite recursion but also avoid false positives. Differential Revision: https://reviews.llvm.org/D60631 > llvm-svn: 358452 llvm-svn: 358466
* Reapply [Support] Add a test for recursive response file expansionShoaib Meenai2019-04-161-0/+34
| | | | | | | | | | | | | | | | Use the appropriate tokenizer to fix the test on Windows. Original commit message: I'm going to be modifying the logic to avoid infinitely recursing on self-referential response files, so add a unit test to verify the expected behavior. Differential Revision: https://reviews.llvm.org/D60630 > llvm-svn: 358451 llvm-svn: 358465
* Revert [Support] Add a test for recursive response file expansionShoaib Meenai2019-04-151-31/+0
| | | | | | | | | This reverts r358451 (git commit c8497467edc5766ae81ffbde58159f8c6af50803) The test breaks a Windows buildbot: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/17016/steps/test-check-all/logs/stdio llvm-svn: 358461
* Revert [Support] Fix recursive response file expansion guardShoaib Meenai2019-04-151-37/+0
| | | | | | | | This reverts r358452 (git commit c8df4fb9c3865eac52a99602c26bbc070098c3d4) A dependent commit breaks the Windows buildbots. llvm-svn: 358460
* [Support] Fix recursive response file expansion guardShoaib Meenai2019-04-151-0/+37
| | | | | | | | | | | | | | | Response file expansion limits the amount of expansion to prevent potential infinite recursion. However, the current logic assumes that any argument beginning with @ is a response file, which is not true for e.g. `-Xlinker -rpath -Xlinker @executable_path/../lib` on Darwin. Having too many of these non-response file arguments beginning with @ prevents actual response files from being expanded. Instead, limit based on the number of successful response file expansions, which should still prevent infinite recursion but also avoid false positives. Differential Revision: https://reviews.llvm.org/D60631 llvm-svn: 358452
* [Support] Add a test for recursive response file expansionShoaib Meenai2019-04-151-0/+31
| | | | | | | | | | I'm going to be modifying the logic to avoid infinitely recursing on self-referential response files, so add a unit test to verify the expected behavior. Differential Revision: https://reviews.llvm.org/D60630 llvm-svn: 358451
* [CommandLineParser] Add DefaultOption flagDon Hinton2019-04-151-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add DefaultOption flag to CommandLineParser which provides a default option or alias, but allows users to override it for some other purpose as needed. Also, add `-h` as a default alias to `-help`, which can be seamlessly overridden by applications like llvm-objdump and llvm-readobj which use `-h` as an alias for other options. (relanding after revert, r358414) Added DefaultOptions.clear() to reset(). Reviewers: alexfh, klimek Reviewed By: klimek Subscribers: kristina, MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D59746 llvm-svn: 358428
* Revert r358337: "[CommandLineParser] Add DefaultOption flag"Ilya Biryukov2019-04-151-61/+0
| | | | | | | The change causes test failures under asan. Reverting to unbreak our integrate. llvm-svn: 358414
* FileCheck [1/12]: Move variable table in new objectThomas Preud'homme2019-04-152-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of a patch series to add support for FileCheck numeric expressions. This specific patch adds a new class to hold pattern matching global state. The table holding the values of FileCheck variable constitutes some sort of global state for the matching phase, yet is passed as parameters of all functions using it. This commit create a new FileCheckPatternContext class pointed at from FileCheckPattern. While it increases the line count, it separates local data from global state. Later commits build on that to add numeric expression global state to that class. Copyright: - Linaro (changes up to diff 183612 of revision D55940) - GraphCore (changes in later versions of revision D55940 and in new revision created off D55940) Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: hiraditya, llvm-commits, probinson, dblaikie, grimar, arichardson, tra, rnk, kristina, hfinkel, rogfer01, JonChesterfield Tags: #llvm Differential Revision: https://reviews.llvm.org/D60381 llvm-svn: 358390
* [DWARF] Fix DWARFVerifier::DieRangeInfo::containsFangrui Song2019-04-151-58/+23
| | | | | | | | | It didn't handle empty LHS correctly. If two ranges of LHS were contiguous and jointly contained one range of RHS, it could also be incorrect. DWARFAddressRange::contains can be removed and its tests can be merged into DWARFVerifier::DieRangeInfo::contains llvm-svn: 358387
* [DWARF] Fix DWARFVerifier::DieRangeInfo::intersectsFangrui Song2019-04-151-0/+3
| | | | | | It was incorrect if RHS had more than 1 ranges and one of the ranges interacted with *this llvm-svn: 358376
* [SelectionDAG] Use KnownBits::computeForAddSub/computeForAddCarryBjorn Pettersson2019-04-151-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Use KnownBits::computeForAddSub/computeForAddCarry in SelectionDAG::computeKnownBits when doing value tracking for addition/subtraction. This should improve the precision of the known bits, as we only used to make a simple estimate of known zeroes. The KnownBits support functions are also able to deduce bits that are known to be one in the result. Reviewers: spatel, RKSimon, nikic, lebedev.ri Reviewed By: nikic Subscribers: nikic, javed.absar, lebedev.ri, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60460 llvm-svn: 358372
* [GlobalISel] Introduce a CSEConfigBase class to allow targets to define ↵Amara Emerson2019-04-151-1/+1
| | | | | | | | | | | | | | their own CSE configs. Because CodeGen can't depend on GlobalISel, we need a way to encapsulate the CSE configs that can be passed between TargetPassConfig and the targets' custom pass configs. This CSEConfigBase allows targets to create custom CSE configs which is then used by the GISel passes for the CSEMIRBuilder. This support will be used in a follow up commit to allow constant-only CSE for -O0 compiles in D60580. llvm-svn: 358368
* [ConstantRange] Simplify unittests after getSetSize was removedFangrui Song2019-04-141-28/+9
| | | | | | | | | | | | | | Reviewers: lebedev.ri, nikic Reviewed By: nikic Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60662 llvm-svn: 358354
* [ConstantRange] Fix unittest after rL358347Fangrui Song2019-04-141-63/+60
| | | | llvm-svn: 358348
* [X86] Use PC-relative mode for the kernel code modelBill Wendling2019-04-131-1/+2
| | | | | | | | | | | | | | | | | | Summary: The Linux kernel uses PC-relative mode, so allow that when the code model is "kernel". Reviewers: craig.topper Reviewed By: craig.topper Subscribers: llvm-commits, kees, nickdesaulniers Tags: #llvm Differential Revision: https://reviews.llvm.org/D60643 llvm-svn: 358343
* [ConstantRange] Disallow NUW | NSW in makeGuaranteedNoWrapRegion()Nikita Popov2019-04-131-106/+0
| | | | | | | | | | | | | | | As motivated in D60598, this drops support for specifying both NUW and NSW in makeGuaranteedNoWrapRegion(). None of the users of this function currently make use of this. When both NUW and NSW are specified, the exact nowrap region has two disjoint parts and makeGNWR() returns one of them. This result doesn't seem to be useful for anything, but makes the semantics of the function fuzzier. Differential Revision: https://reviews.llvm.org/D60632 llvm-svn: 358340
* [CommandLineParser] Add DefaultOption flagDon Hinton2019-04-131-0/+61
| | | | | | | | | | | | | | | | | | | | | | Summary: Add DefaultOption flag to CommandLineParser which provides a default option or alias, but allows users to override it for some other purpose as needed. Also, add `-h` as a default alias to `-help`, which can be seamlessly overridden by applications like llvm-objdump and llvm-readobj which use `-h` as an alias for other options. Reviewers: alexfh, klimek Reviewed By: klimek Subscribers: MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D59746 llvm-svn: 358337
* [ADT] Fix OwningArrayRef's move ctorFangrui Song2019-04-131-0/+7
| | | | llvm-svn: 358332
* [ConstantRange] Clarify makeGuaranteedNoWrapRegion() guarantees; NFCNikita Popov2019-04-121-0/+70
| | | | | | | | | | | | | | | | | | | | | makeGuaranteedNoWrapRegion() is actually makeExactNoWrapRegion() as long as only one of NUW or NSW is specified. This is not obvious from the current documentation, and some code seems to think that it is only exact for single-element ranges. Clarify docs and add tests to be more confident this really holds. There are currently no users of makeGuaranteedNoWrapRegion() that pass both NUW and NSW. I think it would be best to drop support for this entirely and then rename the function to makeExactNoWrapRegion(). Knowing that the no-wrap region is exact is useful, because we can backwards-constrain values. What I have in mind in particular is that LVI should be able to constrain values on edges where the with.overflow overflow flag is false. Differential Revision: https://reviews.llvm.org/D60598 llvm-svn: 358305
* [SCEV] Add option to forget everything in SCEV.Alina Sbirlea2019-04-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Create a method to forget everything in SCEV. Add a cl::opt and PassManagerBuilder option to use this in LoopUnroll. Motivation: Certain Halide applications spend a very long time compiling in forgetLoop, and prefer to forget everything and rebuild SCEV from scratch. Sample difference in compile time reduction: 21.04 to 14.78 using current ToT release build. Testcase showcasing this cannot be opensourced and is fairly large. The option disabled by default, but it may be desirable to enable by default. Evidence in favor (two difference runs on different days/ToT state): File Before (s) After (s) clang-9.bc 7267.91 6639.14 llvm-as.bc 194.12 194.12 llvm-dis.bc 62.50 62.50 opt.bc 1855.85 1857.53 File Before (s) After (s) clang-9.bc 8588.70 7812.83 llvm-as.bc 196.20 194.78 llvm-dis.bc 61.55 61.97 opt.bc 1739.78 1886.26 Reviewers: sanjoy Subscribers: mehdi_amini, jlebar, zzheng, javed.absar, dmgreen, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60144 llvm-svn: 358304
* [KnownBits] Add computeForAddCarry()Nikita Popov2019-04-122-0/+131
| | | | | | | | | | | | | | | | This is for D60460. computeForAddSub() essentially already supports carries because it has to deal with subtractions. This revision extracts a lower-level computeForAddCarry() function, which allows computing the known bits for add (carry known zero), sub (carry known one) and addcarry (carry unknown). As we don't seem to have any yet, I've added a unit test file for KnownBits and exhaustive tests for the new computeForAddCarry() functionality, as well the existing computeForAddSub() function. Differential Revision: https://reviews.llvm.org/D60522 llvm-svn: 358297
* [ConstantRange] Add unsignedMulMayOverflow()Nikita Popov2019-04-111-0/+12
| | | | | | | | | | Same as the other ConstantRange overflow checking methods, but for unsigned mul. In this case there is no cheap overflow criterion, so using umul_ov for the implementation. Differential Revision: https://reviews.llvm.org/D60574 llvm-svn: 358228
* [ConstantRangeTest] Fix typos in test names; NFCNikita Popov2019-04-111-4/+4
| | | | llvm-svn: 358227
* YAMLIO: Fix serialization of strings with embedded nulsPavel Labath2019-04-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: A bug/typo in Output::scalarString caused us to round-trip a StringRef through a const char *. This meant that any strings with embedded nuls were unintentionally cut short at the first such character. (It also could have caused accidental buffer overruns, but it seems that all StringRefs coming into this functions were formed from null-terminated strings.) This patch fixes the bug and adds an appropriate test. Reviewers: sammccall, jhenderson Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60505 llvm-svn: 358176
OpenPOWER on IntegriCloud