summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Analysis/ValueTrackingTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* isBytewiseValue checks ConstantVector element by elementVitaly Buka2019-07-121-1/+1
| | | | | | | | | | | | | | | | Summary: Vector of the same value with few undefs will sill be considered "Bytewise" Reviewers: eugenis, pcc, jfb Reviewed By: jfb Subscribers: dexonsmith, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64031 llvm-svn: 365971
* Return Undef from isBytewiseValue for empty arrays or structsVitaly Buka2019-07-121-4/+4
| | | | | | | | | | | | Reviewers: pcc, eugenis Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64052 llvm-svn: 365864
* Handle IntToPtr in isBytewiseValueVitaly Buka2019-07-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This helps with more efficient use of memset for pattern initialization From @pcc prototype for -ftrivial-auto-var-init=pattern optimizations Binary size change on CTMark, (with -fuse-ld=lld -Wl,--icf=all, similar results with default linker options) ``` master patch diff Os 8.238864e+05 8.238864e+05 0.0 O3 1.054797e+06 1.054797e+06 0.0 Os zero 8.292384e+05 8.292384e+05 0.0 O3 zero 1.062626e+06 1.062626e+06 0.0 Os pattern 8.579712e+05 8.338048e+05 -0.030299 O3 pattern 1.090502e+06 1.067574e+06 -0.020481 ``` Zero vs Pattern on master ``` zero pattern diff Os 8.292384e+05 8.579712e+05 0.036578 O3 1.062626e+06 1.090502e+06 0.025124 ``` Zero vs Pattern with the patch ``` zero pattern diff Os 8.292384e+05 8.338048e+05 0.003333 O3 1.062626e+06 1.067574e+06 0.003193 ``` Reviewers: pcc, eugenis Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63967 llvm-svn: 365858
* [test] Silence gcc 7.4 warning [NFC]Mikael Holmen2019-07-111-1/+1
| | | | | | | | | Without this gcc 7.4.0 complains with ../unittests/Analysis/ValueTrackingTest.cpp:937:66: error: ISO C++11 requires at least one argument for the "..." in a variadic macro [-Werror] ::testing::ValuesIn(IsBytewiseValueTests)); ^ llvm-svn: 365738
* Add IsBytewiseValue unit testVitaly Buka2019-07-101-11/+268
| | | | | | | | | | Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63966 llvm-svn: 365710
* Use "willreturn" in isGuaranteedToTransferExecutionToSuccessorJohannes Doerfert2019-06-271-0/+3
| | | | | | | | | | | | | | | | | | | | | The `willreturn` function attribute guarantees that a function call will come back to the call site if the call is also known not to throw. Therefore, this attribute can be used in `isGuaranteedToTransferExecutionToSuccessor`. Patch by Hideto Ueno (@uenoku) Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63372 llvm-svn: 364580
* [ValueTracking] Known bits support for unsigned saturating add/subNikita Popov2019-03-011-0/+71
| | | | | | | | | | | | | | | | We have two sources of known bits: 1. For adds leading ones of either operand are preserved. For sub leading zeros of LHS and leading ones of RHS become leading zeros in the result. 2. The saturating math is a select between add/sub and an all-ones/ zero value. As such we can carry out the add/sub known bits calculation, and only preseve the known one/zero bits respectively. Differential Revision: https://reviews.llvm.org/D58329 llvm-svn: 355223
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [ValueTracking] Support funnel shifts in computeKnownBits()Nikita Popov2018-12-021-0/+48
| | | | | | | | | | | | If the shift amount is known, we can determine the known bits of the output based on the known bits of two inputs. This is essentially the same functionality as implemented in D54869, but for ValueTracking rather than InstCombine SimplifyDemandedBits. Differential Revision: https://reviews.llvm.org/D55140 llvm-svn: 348091
* [ValueTracking] Make unit tests easier to write; NFCNikita Popov2018-11-301-106/+63
| | | | | | | | | | | | | | Generalize the existing MatchSelectPatternTest class to also work with other types of tests. This reduces the amount of boilerplate necessary to write ValueTracking tests in general, and computeKnownBits tests in particular. The inherited convention is that the function must be @test and the tested instruction %A. Differential Revision: https://reviews.llvm.org/D55141 llvm-svn: 348043
* [ValueTracking] determine sign of 0.0 from select when matching min/max FPSanjay Patel2018-11-041-31/+53
| | | | | | | | | | | | | | | | | | | In PR39475: https://bugs.llvm.org/show_bug.cgi?id=39475 ..we may fail to recognize/simplify fabs() in some cases because we do not canonicalize fcmp with a -0.0 operand. Adding that canonicalization can cause regressions on min/max FP tests, so that's this patch: for the purpose of determining whether something is min/max, let the value returned by the select determine how we treat a 0.0 operand in the fcmp. This patch doesn't actually change the -0.0 to +0.0. It just changes the analysis, so we don't fail to recognize equivalent min/max patterns that only differ in the signbit of 0.0. Differential Revision: https://reviews.llvm.org/D54001 llvm-svn: 346097
* [ValueTracking] peek through 2-input shuffles in ComputeNumSignBitsSanjay Patel2018-11-031-2/+1
| | | | | | | | | | | This patch gives the IR ComputeNumSignBits the same functionality as the DAG version (the code is derived from the existing code). This an extension of the single input shuffle analysis added with D53659. Differential Revision: https://reviews.llvm.org/D53987 llvm-svn: 346071
* [ValueTracking] add test for non-canonical shuffle; NFCSanjay Patel2018-11-021-0/+23
| | | | llvm-svn: 346025
* [ValueTracking] allow non-canonical shuffles when computing signbitsSanjay Patel2018-11-021-0/+20
| | | | | | | This possibility is noted in D53987 for a different case, so we need to adjust the existing code. llvm-svn: 345988
* [ValueTracking] add tests for fmin/fmax; NFCSanjay Patel2018-10-311-0/+176
| | | | llvm-svn: 345777
* [NFC] Rename minnan and maxnan to minimum and maximumThomas Lively2018-10-241-2/+2
| | | | | | | | | | | | | | | Summary: Changes all uses of minnan/maxnan to minimum/maximum globally. These names emphasize that the semantic difference between these operations is more than just NaN-propagation. Reviewers: arsenm, aheejin, dschuff, javed.absar Subscribers: jholewinski, sdardis, wdng, sbc100, jgravelle-google, jrtc27, atanasyan, llvm-commits Differential Revision: https://reviews.llvm.org/D53112 llvm-svn: 345218
* [ValueTracking] Allow select patterns to work on FP vectorsThomas Lively2018-09-281-0/+58
| | | | | | | | | | | | | | | | | | | | Summary: This CL allows constant vectors of floats to be recognized as non-NaN and non-zero in select patterns. This change makes `matchSelectPattern` more powerful generally, but was motivated specifically because I wanted fminnan and fmaxnan to be created for vector versions of the scalar patterns they are created for. Tested with check-all on all targets. A testcase in the WebAssembly backend that tests the non-nan codepath is in an upcoming CL. Reviewers: aheejin, dschuff Subscribers: sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D52324 llvm-svn: 343364
* Infer lowest bits of an integer Multiply when the low bits of the operands ↵Simon Dardis2017-12-091-0/+55
| | | | | | | | | | | | | | | are known When the lowest bits of the operands to an integer multiply are known, the low bits of the result are deducible. Code to deduce known-zero bottom bits already existed, but this change improves on that by deducing known-ones. Patch by: Pedro Ferreira Reviewers: craig.topper, sanjoy, efriedma Differential Revision: https://reviews.llvm.org/D34029 llvm-svn: 320269
* [ValueTracking] Avoid undefined behavior in unittest by not making a named ↵Craig Topper2017-04-141-1/+1
| | | | | | | | | | | | ArrayRef from a std::initializer_list One of the ValueTracking unittests creates a named ArrayRef initialized by a std::initializer_list. The underlying array for an std::initializer_list is only guaranteed to have a lifetime as long as the initializer_list object itself. So this can leave the ArrayRef pointing at an array that no long exists. This fixes this to just create an explicit array instead of an ArrayRef. Differential Revision: https://reviews.llvm.org/D32089 llvm-svn: 300354
* Fix signed-unsigned comparison warningSanjoy Das2017-02-251-1/+1
| | | | llvm-svn: 296274
* [ValueTracking] Don't do an unchecked shift in ComputeNumSignBitsSanjoy Das2017-02-251-0/+19
| | | | | | | | | | | | | | | | | | | | | | Summary: Previously we used to return a bogus result, 0, for IR like `ashr %val, -1`. I've also added an assert checking that `ComputeNumSignBits` at least returns 1. That assert found an already checked in test case where we were returning a bad result for `ashr %val, -1`. Fixes PR32045. Reviewers: spatel, majnemer Reviewed By: spatel, majnemer Subscribers: efriedma, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D30311 llvm-svn: 296273
* Fix an issue with isGuaranteedToTransferExecutionToSuccessorSanjoy Das2016-12-311-0/+51
| | | | | | | | | | | | | | I'm not sure if this was intentional, but today isGuaranteedToTransferExecutionToSuccessor returns true for readonly and argmemonly calls that may throw. This commit changes the function to not implicitly infer nounwind this way. Even if we eventually specify readonly calls as not throwing, isGuaranteedToTransferExecutionToSuccessor is not the best place to infer that. We should instead teach FunctionAttrs or some other such pass to tag readonly functions / calls as nounwind instead. llvm-svn: 290794
* Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini2016-04-141-1/+2
| | | | | | | | | | | At the same time, fixes InstructionsTest::CastInst unittest: yes you can leave the IR in an invalid state and exit when you don't destroy the context (like the global one), no longer now. This is the first part of http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266379
* [ValueTracking] Minor comment change in testJames Molloy2015-09-021-2/+1
| | | | | | This test was updated in r246678 - fix a copypasta in a comment noticed post-commit. llvm-svn: 246679
* [ValueTracking] Look through casts when both operands are casts.James Molloy2015-09-021-0/+42
| | | | | | | | | | | We only looked through casts when one operand was a constant. We can also look through casts when both operands are non-constant, but both are in fact the same cast type. For example: %1 = icmp ult i8 %a, %b %2 = zext i8 %a to i32 %3 = zext i8 %b to i32 %4 = select i1 %1, i32 %2, i32 %3 llvm-svn: 246678
* Add support for floating-point minnum and maxnumJames Molloy2015-08-111-0/+148
The select pattern recognition in ValueTracking (as used by InstCombine and SelectionDAGBuilder) only knew about integer patterns. This teaches it about minimum and maximum operations. matchSelectPattern() has been extended to return a struct containing the existing Flavor and a new enum defining the pattern's behavior when given one NaN operand. C minnum() is defined to return the non-NaN operand in this case, but the idiomatic C "a < b ? a : b" would return the NaN operand. ARM and AArch64 at least have different instructions for these different cases. llvm-svn: 244580
OpenPOWER on IntegriCloud