[BypassSlowDivision] Do not bypass division of hash-like values

[n.bozhenov]

Summary

Disable bypassing if one of the operands looks like a hash value. Slow
division often occurs in hashtable implementations and fast division is
never taken there because a hash value is extremely unlikely to have
enough upper bits set to zero.

A value is considered to be hash-like if it is produced by a

1. XOR operation
2. Multiplication by a constant wider than the shorter type
3. PHI instruction with at least one XOR or MUL+CONST operand.

[n.bozhenov]

This patch is part of a larger patch set:

1. D28196
2. D28197
3. D28198
4. D28199
5. D28200

[jlebar]

lib/Transforms/Utils/BypassSlowDivision.cpp

86

s/the value/a value/

96

Suggest s/quite// and s/generally// -- we weaken it with "generally" then strengthen it with "quite", and then what do we mean exactly? :)

96

unlikely that such values will fit into the shorter type

(If you want to use "for", you could use "uncommon for such values to fit into the shorter type", but I think that's less good here.)

113

s/At this point//

114

No comma needed after "So" here.

114

I don't actually understand what you mean by the first sentence. Can you try to rephrase wrt what the bitcast has to do with constant hoisting?

115

actually a constant

133

We don't need this case?

191

I'd just get rid of the last sentence entirely -- it's clear what's going on.

193

We only want to do this check for the dividend, right? I mean, I guess it doesn't really hurt to do it for the divisor too, but that isn't motivated by hashtables.

test/CodeGen/X86/bypass-slow-division-64.ll

194

Can we test with a constant that *does* fit into 32 bits?

[sanjoy]

Some minor drop-by comments inline

lib/Transforms/Utils/BypassSlowDivision.cpp

101

LLVM style is Width, Depth.

126

Why not:

bool Found = llvm::any_of(P->incoming_values(), [&](Value *V) {
  return isHashLineValue(V, Width, Depth);
});

if (Found)
  return true;

[n.bozhenov]

The patch has been rebased onto D29897.

[n.bozhenov]

lib/Transforms/Utils/BypassSlowDivision.cpp

126

That's cool! But do you think such code would be really easier to read? :)

133

My idea was to add an explicit do-nothing default branch because we are not going to cover all possible enumeration values. But it seems not working, because getOpcode() returns a plain unsigned int. I have deleted the default branch.

193

Basically, yes. This patch was motivated by hashtables and I expect this check to fire mostly for dividends. However, I tried to make the patch as generic as possible. And if we find a divisor that looks like a hash value, disabling bypassing for such a division operation will be a good idea.

test/CodeGen/X86/bypass-slow-division-64.ll

194

Isn't the next test what you're talking about?

[jlebar]

lib/Transforms/Utils/BypassSlowDivision.cpp

126

I do, because it makes the high-level structure of the program explicit. That is, rather than saying "do a loop that does some stuff", we say "check if any elements have property X".

228

Perhaps we can write this as

return C && C->getValue()...

And then below, we can write

return any_of(P->incoming_values(), [&](Value *V) {
  return isHashLikeValue(V, Width, Depth);
});

We could even move the cast into the any_of call.

return any_of(cast<PHINode>(I)->incoming_values(), [&](Value *V) {
  return isHashLikeValue(V, Width, Depth);
});

This is, I think, in the spirit of the LLVM style guide's section about "reducing nesting" and having early returns / breaks.

265

Maybe s/is supposed to detect/tries to detect/

test/CodeGen/X86/bypass-slow-division-fnv.ll

3

Like in the earlier discussion, can we just test this in LLVM IR?

Instead of testing loop unrolling, could we just run your testcase through opt -O3 -unroll-count=4 (maybe we only need unroll-count=2) and check that in? Then here we'd just need to run codegenprepare and check the output of that.

We prefer for unit tests to test small units of code, instead of running the whole optimization pipeline. Whole-pipeline tests are better suited for the test-suite.

10

again s/is supposed to verify/verifies

12

Starting with "reorganized", I don't understand what this is saying, or how it meshes with the comment at the top of the file. Can we harmonize these comments and maybe just have one comment instead of two?

[n.bozhenov]

Moved most of the tests into CodeGenPrepare/NVPTX and changed RUN line in bypass-slow-division-fnv.ll.

[n.bozhenov]

test/CodeGen/X86/bypass-slow-division-fnv.ll

3

We prefer for unit tests to test small units of code, instead of running the whole optimization pipeline. Whole-pipeline tests are better suited for the test-suite.

I believe that the main difference is that the test-suite is for execution tests and unit testing is for lit-tests, isn't it?

Instead of testing loop unrolling, could we just run your testcase through opt -O3 -unroll-count=4 (maybe we only need unroll-count=2) and check that in? Then here we'd just need to run codegenprepare and check the output of that.

That wouldn't make much sense. The recognized patterns are already checked with simpler tests I have put into bypass-slow-div-special-cases.ll. The purpose of this particular file is to make sure that the patterns we recognize are indeed the patterns produced by the middle-end at the maximal optimization level (I have removed the explicit unroll-count option).

The problem this test tries to solve is that the PHI-heuristic in isHashLikeValue is quite fragile. For example, it could be broken if some loop optimization (unrolling/vectorization/whatever) would produce slightly different code with an additional instruction between XOR and REM. This test verifies that there are no such additional instructions and the code is correctly recognized as hash-like.

And since the set of middle-end optimizations and their parameters are target-specific, I would like to have this test X86-specific. It is not an automatically generated test, it has only one CHECK statement, and therefore it is not a problem to have it as an llc test.

[jlebar]

That wouldn't make much sense. The recognized patterns are already checked with simpler tests I have put into bypass-slow-div-special-cases.ll. The purpose of this particular file is to make sure that the patterns we recognize are indeed the patterns produced by the middle-end at the maximal optimization level (I have removed the explicit unroll-count option).

It sounds like there's an implicit "on this particular testcase" at the end of this sentence. "We are checking that we recognize the patterns produced by the middle-end at -O3 *on this particular testcase*."

The problem this test tries to solve is that the PHI-heuristic in isHashLikeValue is quite fragile. For example, it could be broken if some loop optimization (unrolling/vectorization/whatever) would produce slightly different code with an additional instruction between XOR and REM. This test verifies that there are no such additional instructions and the code is correctly recognized as hash-like.

It seems to me that if you think the code is fragile as-is, we should try to make it less fragile, so that a test targeting one specific testcase isn't necessary. For instance, we could increase the search depth some? This would obviate the need for an uber-specific, full-pipeline testcase. It would also keep us honest, in that we're not optimizing for one particular chunk of code.

And since the set of middle-end optimizations and their parameters are target-specific, I would like to have this test X86-specific. It is not an automatically generated test, it has only one CHECK statement, and therefore it is not a problem to have it as an llc test.

If we we really wanted to run the full pipeline, I don't see why we couldn't simply run opt -O3 | opt -codegenprepare. Can you think of a specific bug in this pass that would not be caught by this that would be caught by the lit test?

[n.bozhenov]

That wouldn't make much sense. The recognized patterns are already checked with simpler tests I have put into bypass-slow-div-special-cases.ll. The purpose of this particular file is to make sure that the patterns we recognize are indeed the patterns produced by the middle-end at the maximal optimization level (I have removed the explicit unroll-count option).

It sounds like there's an implicit "on this particular testcase" at the end of this sentence. "We are checking that we recognize the patterns produced by the middle-end at -O3 *on this particular testcase*."

Of course, on this particular testcase. But it is not some arbitrary testcase. While working on this patch I wanted to come up with an heuristic to recognize the most important hashing algorithms. And FNV algorithms are definitely very important algorithms. For example, they are used to calculate hashes for strings in both libstdc++ and libc++.

Unfortunately, the implemented heuristic is still incapable of disabling division bypassing in std::unordered_map<std::string, whatever>. The problem is that the calculated hash value is put to memory before division. So, while I'm happy with XOR and MUL heuristics, I'm not quite satisfied with the PHI heuristic.

The problem this test tries to solve is that the PHI-heuristic in isHashLikeValue is quite fragile. For example, it could be broken if some loop optimization (unrolling/vectorization/whatever) would produce slightly different code with an additional instruction between XOR and REM. This test verifies that there are no such additional instructions and the code is correctly recognized as hash-like.

It seems to me that if you think the code is fragile as-is, we should try to make it less fragile, so that a test targeting one specific testcase isn't necessary. For instance, we could increase the search depth some? This would obviate the need for an uber-specific, full-pipeline testcase. It would also keep us honest, in that we're not optimizing for one particular chunk of code.

Just increasing the search depth doesn't sound right to me because we would be at risk of having many false positive results.

After thinking it over once again, my idea now is to change the PHI heuristic. I believe a better approach would be to test all values instead of any_of and to use a check like

return all_of(P->incoming_values(), [&](Value *V) {
  return getValueRange(V) == VALRNG_LONG;
});

This way it would also be safe (no false positives) to increase the search depth and probably make it unlimited.

I will try to prepare a new patch and upload it by tomorrow.

[n.bozhenov]

Changed the PHI heuristic as planned.

[n.bozhenov]

And since the set of middle-end optimizations and their parameters are target-specific, I would like to have this test X86-specific. It is not an automatically generated test, it has only one CHECK statement, and therefore it is not a problem to have it as an llc test.

If we we really wanted to run the full pipeline, I don't see why we couldn't simply run opt -O3 | opt -codegenprepare. Can you think of a specific bug in this pass that would not be caught by this that would be caught by the lit test?

The reason is that opt -codegenprapare doesn't run BypassSlowDivision for X86. So, I have to run the whole X86 backend to check that the division is not bypassed.

I believe that the new version of the heuristic is much more robust than the previous one. However, a naive implementation didn't work initially. It turned out that hash values weren't recognized because of PHI nodes with undef incoming values generated by loop-unroll. I had to amend the patch to work around the problem.

Earlier I had problems with bitcast instructions. Only after running the whole pipeline test I found that sometimes long constants are hidden behind bitcast instructions.

Obviously, a manually created test would never contain such unexpected things.

Previously you suggested manually running the testcase through opt -O3 ... and checking that in. This wouldn't work either. Some future change in the middle-end will break the pattern recognition in codegenprepare but we never find it out because our codegen input stays the same.

So, I believe that it is worth having a full pipeline test to catch anything unexpected coming from the middle-end and breaking the pattern recognition.

[jlebar]

The reason is that opt -codegenprapare doesn't run BypassSlowDivision for X86. So, I have to run the whole X86 backend to check that the division is not bypassed.

We can't make it an NVPTX test like we did the last time we had this problem?

I believe that the new version of the heuristic is much more robust than the previous one. However, a naive implementation didn't work initially. It turned out that hash values weren't recognized because of PHI nodes with undef incoming values generated by loop-unroll. I had to amend the patch to work around the problem.

It doesn't look like you added any "unit" tests to cover this changed behavior. Was that intentional?

Previously you suggested manually running the testcase through opt -O3 ... and checking that in. This wouldn't work either. Some future change in the middle-end will break the pattern recognition in codegenprepare but we never find it out because our codegen input stays the same.

Sure. It's also true that clang might change how it emits this code, or that you might have a front-end that isn't clang and also emits this code differently.

Ultimately I'm not comfortable LGTM'ing this patch so long as it contains this -O3 test. This is very different than how I understood we write tests. But that might just be my ignorance speaking; what you're trying to do may in fact be perfectly fine; I really don't know enough to say for sure. Let's get a second opinion? If @hfinkel or someone thinks this is the right approach, I'm happy.

lib/Transforms/Utils/BypassSlowDivision.cpp

84

I would prefer VisitedSetTy or something like that.

84

SmallSet<T*> is a typedef for SmallPtrSet. There are 3x as many mentions of SmallPtrSet as SmallSet in LLVM (that's counting all SmallSets, not just SmallSets of pointers), so I think we should call this SmallPtrSet (and change the #include).

227

Can we add a comment explaining why we return true here?

228

Sounds like we should call this VisitedPhis?

229

Why the change from any_of to all_of? You said earlier:

This way it would also be safe (no false positives) to increase the search depth and probably make it unlimited.

I am not sure what you mean by this. Are you making two claims about this change:

a. It's "safe" in that it reduces our false positives, and
b. It lets us safely increase the search depth to infinity?

I don't see how the switch to any_of changes anything with respect to the cost of the recursion. I agree that pretty much any sane code is not going to have deep recursion here. But that's not what I'm worried about. I'm worried about some crazy code that causes us to have quadratic behavior. *That's* what the depth limit is there to protect against.

With respect to (a) I see "safety" opposite of how you've described it. If we declare that something is hash-like, we won't optimize it, and not optimizing is the "safe" thing to do. Therefore the safe/conservative choice is to declare something as "maybe hash-like". Therefore any_of is safer / more conservative than all_of.

I do have a major safety concern here, but it's about how isHashLikeValue is being used in getValueRange. Regardless of whether we use any_of or all_of here, it is *not* safe to return VALRNG_LONG if isHashLikeValue(V). If we return VALRNG_LONG, that is a *promise* that the value is long, and we take advantage of this explicit promise. isHashLikeValue is *not* a promise that the value is long; it's just a heuristic. So that whole thing needs to change. Please also add tests to catch this tricky bug.

(Perhaps you were accidentally working around this bug in getValueRange by using all_of here and that's the source of this confusion.)

[n.bozhenov]

In D28200#692591, @jlebar wrote:

I believe that the new version of the heuristic is much more robust than the previous one. However, a naive implementation didn't work initially. It turned out that hash values weren't recognized because of PHI nodes with undef incoming values generated by loop-unroll. I had to amend the patch to work around the problem.

It doesn't look like you added any "unit" tests to cover this changed behavior. Was that intentional?

I slightly updated a few tests for a newer heuristic, but generally the tests stay the same. It was intentional, yes.

Ultimately I'm not comfortable LGTM'ing this patch so long as it contains this -O3 test. This is very different than how I understood we write tests. But that might just be my ignorance speaking; what you're trying to do may in fact be perfectly fine; I really don't know enough to say for sure. Let's get a second opinion? If @hfinkel or someone thinks this is the right approach, I'm happy.

Ok. I have removed the test in question. Probably I kind of abused the lit testing infrastructure.

[n.bozhenov]

lib/Transforms/Utils/BypassSlowDivision.cpp

228

In the current implementation there are only PHINodes, but in the future it could be extended to cover SELECT instructions as well. Not sure if we should put Phi into the name.

229

Why the change from any_of to all_of? You said earlier:

This way it would also be safe (no false positives) to increase the search depth and probably make it unlimited.

I am not sure what you mean by this. Are you making two claims about this change:

a. It's "safe" in that it reduces our false positives, and
b. It lets us safely increase the search depth to infinity?

Yes, I'm making both of these claims. Previously I considered a PHINode to be hash-like if any of its inputs were hash-like. If I made a search depth unlimited, a multiplication by a long constant would disable bypassing for all divisions reachable from it via a chain of PHINodes. Even if at runtime another input value is fed into those divisions.

But in the current implementation I require all incoming values for a PHINode to be hash-like. It is a much stricter restriction. And because of that, it is safe (conservative) to increase search depth. One multiplication operation cannot poison some far division operation.

I don't see how the switch to any_of changes anything with respect to the cost of the recursion. I agree that pretty much any sane code is not going to have deep recursion here. But that's not what I'm worried about. I'm worried about some crazy code that causes us to have quadratic behavior. *That's* what the depth limit is there to protect against.

As we stop traversal of the IR after finding first value that is neither PHINode nor MUL/XOR, the number of traversed instructions is small for any non-malicious IR. And the recursion depth is limited by the length of the longest chain of consecutive PHINodes.

With respect to (a) I see "safety" opposite of how you've described it. If we declare that something is hash-like, we won't optimize it, and not optimizing is the "safe" thing to do. Therefore the safe/conservative choice is to declare something as "maybe hash-like". Therefore any_of is safer / more conservative than all_of.

My point is that without this patch all long divisions are bypassed. And generally it is a very useful optimization. But in some rare cases this optimization is useless (not harmful) and we would like to disable it. Such disabling is quite risky, because we may get significant performance degradation not bypassing a wrong division. So, here "safety" means "bypass when in doubt".

I do have a major safety concern here, but it's about how isHashLikeValue is being used in getValueRange. Regardless of whether we use any_of or all_of here, it is *not* safe to return VALRNG_LONG if isHashLikeValue(V). If we return VALRNG_LONG, that is a *promise* that the value is long, and we take advantage of this explicit promise. isHashLikeValue is *not* a promise that the value is long; it's just a heuristic. So that whole thing needs to change. Please also add tests to catch this tricky bug.

(Perhaps you were accidentally working around this bug in getValueRange by using all_of here and that's the source of this confusion.)

Actually, the comment at VALRNG_LONG declaration says that it is not a promise. VALRNG_LONG means that a value is *unlikely* to fit into the shorter type. If we needed a promise, we would use ValueTracking only and would never introduce an additional analysis in isHashLikeValue. But for this particular optimization it doesn't matter if a value is *guaranteed* to be long or if it is just *likely* to be long.

[jlebar]

Actually, the comment at VALRNG_LONG declaration says that it is not a promise.

Ah, you're right. I thought that the code that did "no division is needed at all: The quotient is 0 and the remainder is equal to Dividend." checked VALRNG_LONG, but it doesn't.

Regardless of what the comments say, I think this reveals that it is very confusing that we have VALRNG_SHORT, which is a promise, and VALRNG_LONG, which is not.

Maybe we should rename them to VALRNG_KNOWN_SHORT and VALRNG_LIKELY_LONG?

I slightly updated a few tests for a newer heuristic, but generally the tests stay the same. It was intentional, yes.

I can't approve a patch if its tests don't cover its behavior, sorry. If the behavior was worth changing between versions of the patch, it needs test coverage.

As we stop traversal of the IR after finding first value that is neither PHINode nor MUL/XOR, the number of traversed instructions is small for any non-malicious IR. And the recursion depth is limited by the length of the longest chain of consecutive PHINodes.

It's a design goal of LLVM to handle even pathological IR. I think this applies here. I cannot approve this patch if it blows up on IR with many consecutive phi nodes, sorry.

lib/Transforms/Utils/BypassSlowDivision.cpp

228

if (!Visited.insert(I).second)

[n.bozhenov]

In D28200#710710, @jlebar wrote:

Actually, the comment at VALRNG_LONG declaration says that it is not a promise.

Ah, you're right. I thought that the code that did "no division is needed at all: The quotient is 0 and the remainder is equal to Dividend." checked VALRNG_LONG, but it doesn't.

Regardless of what the comments say, I think this reveals that it is very confusing that we have VALRNG_SHORT, which is a promise, and VALRNG_LONG, which is not.

Maybe we should rename them to VALRNG_KNOWN_SHORT and VALRNG_LIKELY_LONG?

Done.

I slightly updated a few tests for a newer heuristic, but generally the tests stay the same. It was intentional, yes.

I can't approve a patch if its tests don't cover its behavior, sorry. If the behavior was worth changing between versions of the patch, it needs test coverage.

I have added one test case which is handled differently by the new and old versions of the patch.

As we stop traversal of the IR after finding first value that is neither PHINode nor MUL/XOR, the number of traversed instructions is small for any non-malicious IR. And the recursion depth is limited by the length of the longest chain of consecutive PHINodes.

It's a design goal of LLVM to handle even pathological IR. I think this applies here. I cannot approve this patch if it blows up on IR with many consecutive phi nodes, sorry.

I have limited the number of visited PHINodes for a single division. Now no more than 16 PHINodes are traversed before giving up.

[jlebar]

\o/

lib/Transforms/Utils/BypassSlowDivision.cpp

static unsigned getHashValue(const DivOpInfo &Val) {
       return (unsigned)(reinterpret_cast<uintptr_t>(Val.Dividend) ^
                         reinterpret_cast<uintptr_t>(Val.Divisor)) ^
                         (unsigned)Val.SignedOp;
     }
   };
 
   typedef DenseMap<DivOpInfo, QuotRemPair> DivCacheTy;
   typedef DenseMap<unsigned, unsigned> BypassWidthsTy;
 }
 
 namespace {
 enum ValueRange {
   /// Operand definitely fits into BypassType. No runtime checks are needed.
   VALRNG_SHORT,
   /// A runtime check is required, as value range is unknown.
   VALRNG_UNKNOWN,
   /// Operand is unlikely to fit into BypassType. The bypassing should be
   /// disabled.
   VALRNG_LONG
 };
 
 class FastDivInsertionTask {
   bool IsValidTask = false;
   Instruction *SlowDivOrRem = nullptr;
   IntegerType *BypassType = nullptr;
   BasicBlock *MainBB = nullptr;
 
+  bool isHashLikeValue(Value *V, int Depth = 0);
   ValueRange getValueRange(Value *Op);
   QuotRemWithBB createSlowBB(BasicBlock *Successor);
   QuotRemWithBB createFastBB(BasicBlock *Successor);
   QuotRemPair createDivRemPhiNodes(QuotRemWithBB &LHS, QuotRemWithBB &RHS,
                                    BasicBlock *PhiBB);
   Value *insertOperandRuntimeCheck(Value *Op1, Value *Op2);
   Optional<QuotRemPair> insertFastDivAndRem();
 
   bool isSignedOp() {
     return SlowDivOrRem->getOpcode() == Instruction::SDiv ||
            SlowDivOrRem->getOpcode() == Instruction::SRem;
   }
   bool isDivisionOp() {
     return SlowDivOrRem->getOpcode() == Instruction::SDiv ||
            SlowDivOrRem->getOpcode() == Instruction::UDiv;
   }
   Type *getSlowType() { return SlowDivOrRem->getType(); }
 
 public:
   FastDivInsertionTask(Instruction *I, const BypassWidthsTy &BypassWidths);
   Value *getReplacement(DivCacheTy &Cache);
 };
 } // anonymous namespace
 
 FastDivInsertionTask::FastDivInsertionTask(Instruction *I,
                                            const BypassWidthsTy &BypassWidths) {
   switch (I->getOpcode()) {
   case Instruction::UDiv:
   case Instruction::SDiv:
   case Instruction::URem:
   case Instruction::SRem:
     SlowDivOrRem = I;
     break;
   default:
     // I is not a div/rem operation.
     return;
   }
 
if (!OptResult)
       return nullptr;
     CacheI = Cache.insert({Key, *OptResult}).first;
   }
 
   QuotRemPair &Value = CacheI->second;
   return isDivisionOp() ? Value.Quotient : Value.Remainder;
 }
 
+/// \brief Check if a value looks like a hash.
+///
+/// The routine is expected to detect values computed using the most common hash
+/// algorithms. Typically, hash computations end with one of the following
+/// instructions:
+///
+/// 1) MUL with a constant wider than BypassType
+/// 2) XOR instruction
+///
+/// And even if we are wrong and the value is not a hash, it is still quite
+/// unlikely that such values will fit into BypassType.
+///
+/// To detect string hash algorithms like FNV we have to look through up to 2
+/// levels of PHI-nodes (if the loop is unrolled) for suspicious MUL and XOR
+/// instructions.
+bool FastDivInsertionTask::isHashLikeValue(Value *V, int Depth) {
+  if (Depth++ > 2)
+    return false;
+
+  Instruction *I = dyn_cast<Instruction>(V);
+  if (!I)
+    return false;
+
+  switch (I->getOpcode()) {
+  case Instruction::Xor:
+    return true;
+  case Instruction::Mul: {
+    // After Constant Hoisting pass, long constants may be represented as
+    // bitcast instructions. As a result, some constants may look like an
+    // instruction at first, and an additional check is necessary to find out if
+    // an operand is actually a constant.
+    Value *Op1 = I->getOperand(1);
+    ConstantInt *C = dyn_cast<ConstantInt>(Op1);
+    if (!C && isa<BitCastInst>(Op1))
+      C = dyn_cast<ConstantInt>(cast<BitCastInst>(Op1)->getOperand(0));
+    if (C && C->getValue().getMinSignedBits() > BypassType->getBitWidth())
+      return true;
+    break;
+  }
+  case Instruction::PHI: {
+    const PHINode *P = cast<PHINode>(I);
+    int NumVal = P->getNumIncomingValues();
+    for (int i = 0; i < NumVal; ++i)
+      if (isHashLikeValue(P->getIncomingValue(i), Depth))
+        return true;
+    break;
+  }
+  }
+
+  return false;
+}
+
 /// Check if an integer value fits into our bypass type.
 ValueRange FastDivInsertionTask::getValueRange(Value *V) {
   unsigned ShortLen = BypassType->getBitWidth();
   unsigned LongLen = V->getType()->getIntegerBitWidth();
 
   assert(LongLen > ShortLen && "Value type must be wider than BypassType");
   unsigned HiBits = LongLen - ShortLen;
 
   const DataLayout &DL = SlowDivOrRem->getModule()->getDataLayout();
   APInt Zeros(LongLen, 0), Ones(LongLen, 0);
 
   computeKnownBits(V, Zeros, Ones, DL);
 
   if (Zeros.countLeadingOnes() >= HiBits)
     return VALRNG_SHORT;
 
   if (Ones.countLeadingZeros() < HiBits)
     return VALRNG_LONG;
 
+  // Long integer divisions are often used in hashtable implementations. It's
+  // not worth bypassing such divisions because hash values are extremely
+  // unlikely to have enough leading zeros. The call below is supposed to detect
+  // values that are unlikely to fit BypassType (including hashes).
+  if (isHashLikeValue(V))
+    return VALRNG_LONG;
+
   return VALRNG_UNKNOWN;
 }
 
 /// Add new basic block for slow div and rem operations and put it before
 /// SuccessorBB.
 QuotRemWithBB FastDivInsertionTask::createSlowBB(BasicBlock *SuccessorBB) {
   QuotRemWithBB DivRemPair;
   DivRemPair.BB = BasicBlock::Create(MainBB->getParent()->getContext(), "",

test/CodeGen/X86/bypass-slow-division-64.ll

 ; CHECK-NEXT:    addq %rcx, %rax
 ; CHECK-NEXT:    retq
   %a.1 = zext i32 %a to i64
   %div = udiv i64 %a.1, %b
   %rem = urem i64 %a.1, %b
   %res = add i64 %div, %rem
   ret i64 %res
 }
+
+; Do not bypass a division if one of the operands looks like a hash value.
+define i64 @Test_dont_bypass_xor(i64 %a, i64 %b, i64 %l) nounwind {
+; CHECK-LABEL: Test_dont_bypass_xor
+; CHECK-NOT: divl
+  %c = xor i64 %a, %b
+  %res = udiv i64 %c, %l
+  ret i64 %res
+}
+
+define i64 @Test_dont_bypass_phi_xor(i64 %a, i64 %b, i64 %l) nounwind {
+; CHECK-LABEL: Test_dont_bypass_phi_xor
+; CHECK-NOT: divl
+entry:
+  %cmp = icmp eq i64 %b, 0
+  br i1 %cmp, label %merge, label %xorpath
+
+xorpath:
+  %c = xor i64 %a, %b
+  br label %merge
+
+merge:
+  %e = phi i64 [ 0, %entry ], [ %c, %xorpath ]
+  %res = sdiv i64 %e, %l
+  ret i64 %res
+}
+
+define i64 @Test_dont_bypass_mul_long_const(i64 %a, i64 %l) nounwind {
+; CHECK-LABEL: Test_dont_bypass_mul_long_const
+; CHECK-NOT: divl
+  %c = mul i64 %a, 5229553307 ; the constant doesn't fit 32 bits
+  %res = urem i64 %c, %l
+  ret i64 %res
+}
+
+define i64 @Test_bypass_mul_short_const(i64 %a, i64 %l) nounwind {
+; CHECK-LABEL: Test_bypass_mul_short_const
+; CHECK-DAG: divl
+; CHECK-DAG: divq
+  %c = mul i64 %a, -42
+  %res = urem i64 %c, %l
+  ret i64 %res
+}

test/CodeGen/X86/bypass-slow-division-fnv.ll

+; Check that division is not bypassed for hash-like values in optimized code.
+; RUN: opt < %s -O3 -unroll-count=4 | llc -mattr=+idivq-to-divl | FileCheck %s
+; CHECK-NOT: divl
+
+target triple = "x86_64-unknown-linux-gnu"
+
+; Fowler–Noll–Vo hash functions.
+;
+; A simple but widely used hash algorithm with hash operations hidden inside a
+; (probably) unrolled loop. The test is supposed to verify that such code is
+; recognized even after running loop unrolling on it and any other applicable
+; optimizations.
+
+define i64 @fnv_1(i8* %str, i64 %len, i64 %tsz) nounwind {
+entry:
+  br label %for.cond
+
+for.cond:                                         ; preds = %for.inc, %entry
+  %i.0 = phi i64 [ 0, %entry ], [ %inc, %for.inc ]
+  %hash.0 = phi i64 [ -3750763034362895579, %entry ], [ %xor, %for.inc ]
+  %cmp = icmp ult i64 %i.0, %len
+  br i1 %cmp, label %for.body, label %for.end
+
+for.body:                                         ; preds = %for.cond
+  %mul = mul i64 %hash.0, 1099511628211
+  %arrayidx = getelementptr inbounds i8, i8* %str, i64 %i.0
+  %0 = load i8, i8* %arrayidx, align 1
+  %conv = sext i8 %0 to i64
+  %xor = xor i64 %mul, %conv
+  br label %for.inc
+
+for.inc:                                          ; preds = %for.body
+  %inc = add i64 %i.0, 1
+  br label %for.cond
+
+for.end:                                          ; preds = %for.cond
+  %rem = urem i64 %hash.0, %tsz
+  ret i64 %rem
+}
+
+
+define i64 @fnv_1a(i8* %str, i64 %len, i64 %tsz) nounwind {
+  entry:
+  br label %for.cond
+
+for.cond:                                         ; preds = %for.inc, %entry
+  %i.0 = phi i64 [ 0, %entry ], [ %inc, %for.inc ]
+  %hash.0 = phi i64 [ -3750763034362895579, %entry ], [ %mul, %for.inc ]
+  %cmp = icmp ult i64 %i.0, %len
+  br i1 %cmp, label %for.body, label %for.end
+
+for.body:                                         ; preds = %for.cond
+  %arrayidx = getelementptr inbounds i8, i8* %str, i64 %i.0
+  %0 = load i8, i8* %arrayidx, align 1
+  %conv = sext i8 %0 to i64
+  %xor = xor i64 %hash.0, %conv
+  %mul = mul i64 %xor, 1099511628211
+  br label %for.inc
+
+for.inc:                                          ; preds = %for.body
+  %inc = add i64 %i.0, 1
+  br label %for.cond
+
+for.end:                                          ; preds = %for.cond
+  %rem = urem i64 %hash.0, %tsz
+  ret i64 %rem
+}