maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/unittests/IR/PatternMatch.cpp

299 lines
11 KiB
C++
Raw Normal View History

PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
//===---- llvm/unittest/IR/PatternMatch.cpp - PatternMatch unit tests ----===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "llvm/ADT/STLExtras.h"
#include "llvm/Analysis/ValueTracking.h"
#include "llvm/IR/BasicBlock.h"
#include "llvm/IR/Constants.h"
#include "llvm/IR/DataLayout.h"
#include "llvm/IR/DerivedTypes.h"
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
#include "llvm/IR/Function.h"
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
#include "llvm/IR/IRBuilder.h"
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
#include "llvm/IR/Instructions.h"
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/MDBuilder.h"
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
#include "llvm/IR/Module.h"
[Modules] Move the NoFolder into the IR library as it creates instructions. llvm-svn: 202834
2014-03-04 20:05:47 +08:00
#include "llvm/IR/NoFolder.h"
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
#include "llvm/IR/Operator.h"
[Modules] Move the LLVM IR pattern match header into the IR library, it obviously is coupled to the IR. llvm-svn: 202818
2014-03-04 19:08:18 +08:00
#include "llvm/IR/PatternMatch.h"
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
#include "llvm/IR/Type.h"
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
#include "gtest/gtest.h"
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
using namespace llvm;
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
using namespace llvm::PatternMatch;
namespace {
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
struct PatternMatchTest : ::testing::Test {
LLVMContext Ctx;
Replace OwningPtr<T> with std::unique_ptr<T>. 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
2014-03-06 13:51:42 +08:00
std::unique_ptr<Module> M;
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
Function *F;
BasicBlock *BB;
Remove PreserveNames template parameter from IRBuilder This reapplies r263258, which was reverted in r263321 because of issues on Clang side. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263393
2016-03-14 05:05:13 +08:00
IRBuilder<NoFolder> IRB;
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
PatternMatchTest()
: M(new Module("PatternMatchTestModule", Ctx)),
F(Function::Create(
FunctionType::get(Type::getVoidTy(Ctx), /* IsVarArg */ false),
Function::ExternalLinkage, "f", M.get())),
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
BB(BasicBlock::Create(Ctx, "entry", F)), IRB(BB) {}
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
};
Add in a unittest for the one-use pattern matcher. llvm-svn: 198552
2014-01-05 17:14:53 +08:00
TEST_F(PatternMatchTest, OneUse) {
// Build up a little tree of values:
//
// One = (1 + 2) + 42
// Two = One + 42
// Leaf = (Two + 8) + (Two + 13)
Value *One = IRB.CreateAdd(IRB.CreateAdd(IRB.getInt32(1), IRB.getInt32(2)),
IRB.getInt32(42));
Value *Two = IRB.CreateAdd(One, IRB.getInt32(42));
Value *Leaf = IRB.CreateAdd(IRB.CreateAdd(Two, IRB.getInt32(8)),
IRB.CreateAdd(Two, IRB.getInt32(13)));
Value *V;
EXPECT_TRUE(m_OneUse(m_Value(V)).match(One));
EXPECT_EQ(One, V);
EXPECT_FALSE(m_OneUse(m_Value()).match(Two));
EXPECT_FALSE(m_OneUse(m_Value()).match(Leaf));
}
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
TEST_F(PatternMatchTest, FloatingPointOrderedMin) {
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
Type *FltTy = IRB.getFloatTy();
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
Value *L = ConstantFP::get(FltTy, 1.0);
Value *R = ConstantFP::get(FltTy, 2.0);
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
Value *MatchL, *MatchR;
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test OLT.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_OrdFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOLT(L, R), L, R)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test OLE.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_OrdFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOLE(L, R), L, R)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test no match on OGE.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_FALSE(m_OrdFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOGE(L, R), L, R)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test no match on OGT.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_FALSE(m_OrdFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOGT(L, R), L, R)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test match on OGE with inverted select.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_OrdFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOGE(L, R), R, L)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test match on OGT with inverted select.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_OrdFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOGT(L, R), R, L)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
}
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
TEST_F(PatternMatchTest, FloatingPointOrderedMax) {
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
Type *FltTy = IRB.getFloatTy();
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
Value *L = ConstantFP::get(FltTy, 1.0);
Value *R = ConstantFP::get(FltTy, 2.0);
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
Value *MatchL, *MatchR;
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test OGT.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_OrdFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOGT(L, R), L, R)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test OGE.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_OrdFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOGE(L, R), L, R)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test no match on OLE.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_FALSE(m_OrdFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOLE(L, R), L, R)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test no match on OLT.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_FALSE(m_OrdFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOLT(L, R), L, R)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test match on OLE with inverted select.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_OrdFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOLE(L, R), R, L)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
// Test match on OLT with inverted select.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_OrdFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpOLT(L, R), R, L)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
}
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
TEST_F(PatternMatchTest, FloatingPointUnorderedMin) {
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
Type *FltTy = IRB.getFloatTy();
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
Value *L = ConstantFP::get(FltTy, 1.0);
Value *R = ConstantFP::get(FltTy, 2.0);
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
Value *MatchL, *MatchR;
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test ULT.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_UnordFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpULT(L, R), L, R)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test ULE.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_UnordFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpULE(L, R), L, R)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test no match on UGE.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_FALSE(m_UnordFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpUGE(L, R), L, R)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test no match on UGT.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_FALSE(m_UnordFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpUGT(L, R), L, R)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test match on UGE with inverted select.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_UnordFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpUGE(L, R), R, L)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test match on UGT with inverted select.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_UnordFMin(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpUGT(L, R), R, L)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
}
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
TEST_F(PatternMatchTest, FloatingPointUnorderedMax) {
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
Type *FltTy = IRB.getFloatTy();
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
Value *L = ConstantFP::get(FltTy, 1.0);
Value *R = ConstantFP::get(FltTy, 2.0);
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
Value *MatchL, *MatchR;
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test UGT.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_UnordFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpUGT(L, R), L, R)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test UGE.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_UnordFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpUGE(L, R), L, R)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test no match on ULE.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_FALSE(m_UnordFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpULE(L, R), L, R)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test no match on ULT.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_FALSE(m_UnordFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpULT(L, R), L, R)));
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test match on ULE with inverted select.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_UnordFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpULE(L, R), R, L)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
// Test match on ULT with inverted select.
Use a shorter name for the IRBuilder member. This will help the tests I'm adding next be a lot more readable. llvm-svn: 198534
2014-01-05 10:23:11 +08:00
EXPECT_TRUE(m_UnordFMax(m_Value(MatchL), m_Value(MatchR))
.match(IRB.CreateSelect(IRB.CreateFCmpULT(L, R), R, L)));
Simplify the PatternMatch unittest by giving it a module, function, and 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
2014-01-05 10:07:20 +08:00
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
}
Add support to the pattern match library for matching NSW and NUW 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
2014-01-05 11:28:29 +08:00
TEST_F(PatternMatchTest, OverflowingBinOps) {
Value *L = IRB.getInt32(1);
Value *R = IRB.getInt32(2);
Value *MatchL, *MatchR;
EXPECT_TRUE(
m_NSWAdd(m_Value(MatchL), m_Value(MatchR)).match(IRB.CreateNSWAdd(L, R)));
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 06:29:17 +08:00
MatchL = MatchR = nullptr;
Add support to the pattern match library for matching NSW and NUW 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
2014-01-05 11:28:29 +08:00
EXPECT_TRUE(
m_NSWSub(m_Value(MatchL), m_Value(MatchR)).match(IRB.CreateNSWSub(L, R)));
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 06:29:17 +08:00
MatchL = MatchR = nullptr;
Add support to the pattern match library for matching NSW and NUW 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
2014-01-05 11:28:29 +08:00
EXPECT_TRUE(
m_NSWMul(m_Value(MatchL), m_Value(MatchR)).match(IRB.CreateNSWMul(L, R)));
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 06:29:17 +08:00
MatchL = MatchR = nullptr;
Add support to the pattern match library for matching NSW and NUW 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
2014-01-05 11:28:29 +08:00
EXPECT_TRUE(m_NSWShl(m_Value(MatchL), m_Value(MatchR)).match(
IRB.CreateShl(L, R, "", /* NUW */ false, /* NSW */ true)));
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
EXPECT_TRUE(
m_NUWAdd(m_Value(MatchL), m_Value(MatchR)).match(IRB.CreateNUWAdd(L, R)));
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 06:29:17 +08:00
MatchL = MatchR = nullptr;
Add support to the pattern match library for matching NSW and NUW 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
2014-01-05 11:28:29 +08:00
EXPECT_TRUE(
m_NUWSub(m_Value(MatchL), m_Value(MatchR)).match(IRB.CreateNUWSub(L, R)));
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 06:29:17 +08:00
MatchL = MatchR = nullptr;
Add support to the pattern match library for matching NSW and NUW 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
2014-01-05 11:28:29 +08:00
EXPECT_TRUE(
m_NUWMul(m_Value(MatchL), m_Value(MatchR)).match(IRB.CreateNUWMul(L, R)));
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
[C++11] Use 'nullptr'. llvm-svn: 210442
2014-06-09 06:29:17 +08:00
MatchL = MatchR = nullptr;
Add support to the pattern match library for matching NSW and NUW 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
2014-01-05 11:28:29 +08:00
EXPECT_TRUE(m_NUWShl(m_Value(MatchL), m_Value(MatchR)).match(
IRB.CreateShl(L, R, "", /* NUW */ true, /* NSW */ false)));
EXPECT_EQ(L, MatchL);
EXPECT_EQ(R, MatchR);
EXPECT_FALSE(m_NSWAdd(m_Value(), m_Value()).match(IRB.CreateAdd(L, R)));
EXPECT_FALSE(m_NSWAdd(m_Value(), m_Value()).match(IRB.CreateNUWAdd(L, R)));
EXPECT_FALSE(m_NSWAdd(m_Value(), m_Value()).match(IRB.CreateNSWSub(L, R)));
EXPECT_FALSE(m_NSWSub(m_Value(), m_Value()).match(IRB.CreateSub(L, R)));
EXPECT_FALSE(m_NSWSub(m_Value(), m_Value()).match(IRB.CreateNUWSub(L, R)));
EXPECT_FALSE(m_NSWSub(m_Value(), m_Value()).match(IRB.CreateNSWAdd(L, R)));
EXPECT_FALSE(m_NSWMul(m_Value(), m_Value()).match(IRB.CreateMul(L, R)));
EXPECT_FALSE(m_NSWMul(m_Value(), m_Value()).match(IRB.CreateNUWMul(L, R)));
EXPECT_FALSE(m_NSWMul(m_Value(), m_Value()).match(IRB.CreateNSWAdd(L, R)));
EXPECT_FALSE(m_NSWShl(m_Value(), m_Value()).match(IRB.CreateShl(L, R)));
EXPECT_FALSE(m_NSWShl(m_Value(), m_Value()).match(
IRB.CreateShl(L, R, "", /* NUW */ true, /* NSW */ false)));
EXPECT_FALSE(m_NSWShl(m_Value(), m_Value()).match(IRB.CreateNSWAdd(L, R)));
EXPECT_FALSE(m_NUWAdd(m_Value(), m_Value()).match(IRB.CreateAdd(L, R)));
EXPECT_FALSE(m_NUWAdd(m_Value(), m_Value()).match(IRB.CreateNSWAdd(L, R)));
EXPECT_FALSE(m_NUWAdd(m_Value(), m_Value()).match(IRB.CreateNUWSub(L, R)));
EXPECT_FALSE(m_NUWSub(m_Value(), m_Value()).match(IRB.CreateSub(L, R)));
EXPECT_FALSE(m_NUWSub(m_Value(), m_Value()).match(IRB.CreateNSWSub(L, R)));
EXPECT_FALSE(m_NUWSub(m_Value(), m_Value()).match(IRB.CreateNUWAdd(L, R)));
EXPECT_FALSE(m_NUWMul(m_Value(), m_Value()).match(IRB.CreateMul(L, R)));
EXPECT_FALSE(m_NUWMul(m_Value(), m_Value()).match(IRB.CreateNSWMul(L, R)));
EXPECT_FALSE(m_NUWMul(m_Value(), m_Value()).match(IRB.CreateNUWAdd(L, R)));
EXPECT_FALSE(m_NUWShl(m_Value(), m_Value()).match(IRB.CreateShl(L, R)));
EXPECT_FALSE(m_NUWShl(m_Value(), m_Value()).match(
IRB.CreateShl(L, R, "", /* NUW */ false, /* NSW */ true)));
EXPECT_FALSE(m_NUWShl(m_Value(), m_Value()).match(IRB.CreateNUWAdd(L, R)));
}
PatternMatch: Matcher for (un)ordered floating point min/max 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
2013-05-05 09:54:46 +08:00
} // anonymous namespace.