summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/IR/PatternMatch.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove unused variable. NFC.Michael Liao2019-12-031-1/+0
|
* [APInt][PatternMatch] Add 'is non-positive' predicateRoman Lebedev2019-12-031-0/+24
| | | | | It will be useful for implementing the fold mentioned in https://bugs.llvm.org/show_bug.cgi?id=44100#c4
* [PatternMatch] Add support for matching intrinsics with 5 operands.Florian Hahn2019-12-021-0/+79
| | | | | | | | | | | | | | Summary: Also adds a test to the pattern matching unit tests. Reviewers: spatel, craig.topper, RKSimon, majnemer, lebedev.ri Reviewed By: spatel Subscribers: merge_guards_bot, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70892
* [PatternMatch] Add m_WithOverflowInst and m_ExtractValue matchersDavid Green2019-10-311-0/+24
| | | | | | Used in D69245, these add pattern matchers for the WithOverflowInst (capturing the result) and the ExtractValue instructions taking a template parameter specifying the element being extracted.
* [PatternMatch] Add m_SExtOrSelf(), m_ZExtOrSExtOrSelf() matchers + unittestsRoman Lebedev2019-09-271-0/+36
| | | | | | | | | | m_SExtOrSelf() is for consistency. m_ZExtOrSExtOrSelf() is motivated by the D68103/r373106 : sometimes it is useful to look past any extensions of the shift amount, and m_ZExtOrSExtOrSelf() may be exactly the tool to do that. llvm-svn: 373128
* [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][PatternMatch] Introduce m_NegatedPower2() matcherRoman Lebedev2019-07-251-0/+21
| | | | | | | | | | | | | | | | | | | Summary: It is a good idea to do as much matching inside of `match()` as possible. If some checking is done afterwards, and we don't fold because of it, chances are we may have missed some commutative pattern. Reviewers: spatel, craig.topper, RKSimon Reviewed By: spatel, RKSimon Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64038 llvm-svn: 367017
* [IR][PatternMatch] introduce m_Unless() matcherRoman Lebedev2019-07-251-0/+16
| | | | | | | | | | | | | | | | | | | Summary: I don't think it already exists? I don't see it at least. It is important to have it because else we'll do some checks after `match()`, and that may result in missed folds in commutative nodes. Reviewers: spatel, craig.topper, RKSimon, majnemer Reviewed By: spatel Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64037 llvm-svn: 367016
* Revert "r366069: [PatternMatch] Implement matching code for LibFunc"Ilya Biryukov2019-07-151-37/+1
| | | | | | | Reason: the change introduced a layering violation by adding a dependency on IR to Analysis. llvm-svn: 366081
* [PatternMatch] Implement matching code for LibFuncDmitry Venikov2019-07-151-1/+37
| | | | | | | | | | | | | | | | Summary: Provides m_LibFunc pattern that can be used to match LibFuncs. Reviewers: spatel, hfinkel, efriedma, lebedev.ri Reviewed By: lebedev.ri Subscribers: lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D42047 llvm-svn: 366069
* [PatternMatch] Generalize m_SpecificInt_ULT() to take ICmpInst::PredicateRoman Lebedev2019-07-101-9/+378
| | | | | | | As discussed in the original review, this may be useful, so let's just do it. llvm-svn: 365652
* [IR][Patternmatch] Add m_SpecificInt_ULT() predicateRoman Lebedev2019-06-291-0/+21
| | | | | | | | | | | | | | | | | | | | Summary: Match an integer or vector with every element unsigned less than the Threshold. For vectors, this includes constants with undefined elements. FIXME: is it worth generalizing this to simply take ICmpInst::Predicate? Reviewers: craig.topper, spatel, nikic Reviewed By: spatel Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63811 llvm-svn: 364711
* Update PatternMatcher for FNegCameron McInally2019-05-031-0/+29
| | | | | | | | Match both FNeg(X) and FSub(+-0.0, X) in FNeg_match Differential Revision: https://reviews.llvm.org/D61520 llvm-svn: 359936
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-011-1/+1
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* 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
* [PatternMatch] Handle undef vectors consistentlySanjay Patel2018-11-201-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the issue noticed in D54532. The problem is that cst_pred_ty-based matchers like m_Zero() currently do not match scalar undefs (as expected), but *do* match vector undefs. This may lead to optimization inconsistencies in rare cases. There is only one existing test for which output changes, reverting the change from D53205. The reason here is that vector fsub undef, %x is no longer matched as an m_FNeg(). While I think that the new output is technically worse than the previous one, it is consistent with scalar, and I don't think it's really important either way (generally that undef should have been folded away prior to reassociation.) I've also added another test case for this issue based on InstructionSimplify. It took some effort to find that one, as in most cases undef folds are either checked first -- and in the cases where they aren't it usually happens to not make a difference in the end. This is the only case I was able to come up with. Prior to this patch the test case simplified to undef in the scalar case, but zeroinitializer in the vector case. Patch by: @nikic (Nikita Popov) Differential Revision: https://reviews.llvm.org/D54631 llvm-svn: 347318
* [PatternMatch] Add m_Store pattern match helperSjoerd Meijer2018-06-201-0/+36
| | | | | | Differential Revision: https://reviews.llvm.org/D48279 llvm-svn: 335100
* [PatternMatch] Stabilize the matching order of commutative matchersRoman Lebedev2018-04-271-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, we 1. match `LHS` matcher to the `first` operand of binary operator, 2. and then match `RHS` matcher to the `second` operand of binary operator. If that does not match, we swap the `LHS` and `RHS` matchers: 1. match `RHS` matcher to the `first` operand of binary operator, 2. and then match `LHS` matcher to the `second` operand of binary operator. This works ok. But it complicates writing of commutative matchers, where one would like to match (`m_Value()`) the value on one side, and use (`m_Specific()`) it on the other side. This is additionally complicated by the fact that `m_Specific()` stores the `Value *`, not `Value **`, so it won't work at all out of the box. The last problem is trivially solved by adding a new `m_c_Specific()` that stores the `Value **`, not `Value *`. I'm choosing to add a new matcher, not change the existing one because i guess all the current users are ok with existing behavior, and this additional pointer indirection may have performance drawbacks. Also, i'm storing pointer, not reference, because for some mysterious-to-me reason it did not work with the reference. The first one appears trivial, too. Currently, we 1. match `LHS` matcher to the `first` operand of binary operator, 2. and then match `RHS` matcher to the `second` operand of binary operator. If that does not match, we swap the ~~`LHS` and `RHS` matchers~~ **operands**: 1. match ~~`RHS`~~ **`LHS`** matcher to the ~~`first`~~ **`second`** operand of binary operator, 2. and then match ~~`LHS`~~ **`RHS`** matcher to the ~~`second`~ **`first`** operand of binary operator. Surprisingly, `$ ninja check-llvm` still passes with this. But i expect the bots will disagree.. The motivational unittest is included. I'd like to use this in D45664. Reviewers: spatel, craig.topper, arsenm, RKSimon Reviewed By: craig.topper Subscribers: xbolva00, wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D45828 llvm-svn: 331085
* [PatternMatch] Add matchers for vector operationsDaniel Neilson2018-03-281-0/+108
| | | | | | | | Summary: There aren't any matchers for the three vector operations: insertelement, extractelement, and shufflevector. This patch adds them as well as corresponding unit tests. llvm-svn: 328709
* Fix m_[Ord|Unord][FMin|FMax] matchers to correctly match ordering.Craig Topper2017-06-131-16/+61
| | | | | | | | | | | Previously, the matching was done incorrectly for the case where operands for FCmpInst and SelectInst were in opposite order. Patch by Andrei Elovikov. Differential Revision: https://reviews.llvm.org/D33185 llvm-svn: 305308
* Re-sort #include lines for unittests. This uses a slightly modifiedChandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | clang-format (https://reviews.llvm.org/D33932) to keep primary headers at the top and handle new utility headers like 'gmock' consistently with other utility headers. No other change was made. I did no manual edits, all of this is clang-format. This should allow other changes to have more clear and focused diffs, and is especially motivated by moving some headers into more focused libraries. llvm-svn: 304786
* Add support to paternmatch for simple const Value cases.Pete Cooper2016-08-121-0/+27
| | | | | | | | | | | | | Pattern match has some paths which can operate on constant instructions, but not all. This adds a version of m_value() to return const Value* and changes ICmp matching to use auto so that it can match both constant and mutable instructions. Tests also included for both mutable and constant ICmpInst matching. This will be used in a future commit to constify ValueTracking.cpp. llvm-svn: 278570
* Remove PreserveNames template parameter from IRBuilderMehdi Amini2016-03-131-1/+1
| | | | | | | | This reapplies r263258, which was reverted in r263321 because of issues on Clang side. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263393
* Temporarily revert:Eric Christopher2016-03-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ae14bf6488e8441f0f6d74f00455555f6f3943ac Author: Mehdi Amini <mehdi.amini@apple.com> Date: Fri Mar 11 17:15:50 2016 +0000 Remove PreserveNames template parameter from IRBuilder Summary: Following r263086, we are now relying on a flag on the Context to discard Value names in release builds. Reviewers: chandlerc Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18023 From: Mehdi Amini <mehdi.amini@apple.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263258 91177308-0d34-0410-b5e6-96231b3b80d8 until we can figure out what to do about clang and Release build testing. This reverts commit 263258. llvm-svn: 263321
* Remove PreserveNames template parameter from IRBuilderMehdi Amini2016-03-111-1/+1
| | | | | | | | | | | | | | | Summary: Following r263086, we are now relying on a flag on the Context to discard Value names in release builds. Reviewers: chandlerc Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18023 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263258
* [C++11] Use 'nullptr'.Craig Topper2014-06-081-6/+6
| | | | llvm-svn: 210442
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+1
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* [Modules] Move the NoFolder into the IR library as it createsChandler Carruth2014-03-041-1/+1
| | | | | | instructions. llvm-svn: 202834
* [Modules] Move the LLVM IR pattern match header into the IR library, itChandler Carruth2014-03-041-1/+1
| | | | | | obviously is coupled to the IR. llvm-svn: 202818
* Add in a unittest for the one-use pattern matcher.Chandler Carruth2014-01-051-0/+20
| | | | llvm-svn: 198552
* Add support to the pattern match library for matching NSW and NUWChandler Carruth2014-01-051-0/+74
| | | | | | | | | | | instructions. I needed this for a quick experiment I was making, and while I've no idea if that will ever get committed, I didn't want to throw away the pattern match code and for anyone else to have to write it again. I've added unittests to make sure this works correctly. In fun news, this also uncovered the IRBuilder bug. Doh! llvm-svn: 198541
* Use a shorter name for the IRBuilder member. This will help the testsChandler Carruth2014-01-051-54/+54
| | | | | | I'm adding next be a lot more readable. llvm-svn: 198534
* Simplify the PatternMatch unittest by giving it a module, function, andChandler Carruth2014-01-051-166/+105
| | | | | | | | | basic block to hold instructions, and managing all of their lifetimes in a fixture. This makes it easy to sink the expectations into the test cases themselves which also makes things a bit more explicit and clearer IMO. llvm-svn: 198532
* PatternMatch: Matcher for (un)ordered floating point min/maxArnold Schwaighofer2013-05-051-0/+265
Add support for matching 'ordered' and 'unordered' floating point min/max constructs. In LLVM we can express min/max functions as a combination of compare and select. We have support for matching such constructs for integers but not for floating point. In floating point math there is no total order because of the presence of 'NaN'. Therefore, we have to be careful to preserve the original fcmp semantics when interpreting floating point compare select combinations as a minimum or maximum function. The resulting 'ordered/unordered' floating point maximum function has to select the same value as the select/fcmp combination it is based on. ordered_max(x,y) = max(x,y) iff x and y are not NaN, y otherwise unordered_max(x,y) = max(x,y) iff x and y are not NaN, x otherwise ordered_min(x,y) = min(x,y) iff x and y are not NaN, y otherwise unordered_min(x,y) = min(x,y) iff x and y are not NaN, x otherwise This matches the behavior of the underlying select(fcmp(olt/ult/.., L, R), L, R) construct. Any code using this predicate has to preserve this semantics. A follow-up patch will use this to implement floating point min/max reductions in the vectorizer. radar://13723044 llvm-svn: 181143
OpenPOWER on IntegriCloud