diff options
author | Simon Pilgrim <llvm-dev@redking.me.uk> | 2019-07-27 12:48:46 +0000 |
---|---|---|
committer | Simon Pilgrim <llvm-dev@redking.me.uk> | 2019-07-27 12:48:46 +0000 |
commit | 8a5267178208c4f857afe7b84f45f1d0678282c7 (patch) | |
tree | 53f1b3ee3b5ca04a34a1039e7fb615559da9b9fc /lldb/source/Commands/CommandObjectProcess.cpp | |
parent | 51bfb84852e5c3bf746a34a455504c70540a55c3 (diff) | |
download | llvm-8a5267178208c4f857afe7b84f45f1d0678282c7.zip llvm-8a5267178208c4f857afe7b84f45f1d0678282c7.tar.gz llvm-8a5267178208c4f857afe7b84f45f1d0678282c7.tar.bz2 |
[SelectionDAG] Check for any recursion depth greater than or equal to limit instead of just equal the limit.
If anything called the recursive isKnownNeverNaN/computeKnownBits/ComputeNumSignBits/SimplifyDemandedBits/SimplifyMultipleUseDemandedBits with an incorrect depth then we could continue to recurse if we'd already exceeded the depth limit.
This replaces the limit check (Depth == 6) with a (Depth >= 6) to make sure that we don't circumvent it.
This causes a couple of regressions as a mixture of calls (SimplifyMultipleUseDemandedBits + combineX86ShufflesRecursively) were calling with depths that were already over the limit. I've fixed SimplifyMultipleUseDemandedBits to not do this. combineX86ShufflesRecursively is trickier as we get a lot of regressions if we reduce its own limit from 8 to 6 (it also starts at Depth == 1 instead of Depth == 0 like the others....) - I'll see what I can do in future patches.
llvm-svn: 367171
Diffstat (limited to 'lldb/source/Commands/CommandObjectProcess.cpp')
0 files changed, 0 insertions, 0 deletions