search for: pr32037

...mbine. > I rebased it yesterday, so it should be fairly easy to apply: https://reviews.llvm.org/D31239 - Seeing what this does to the performance of the > benchmarks mentioned in this thread (among others) would certainly be interesting. Thanks! I only have the one rough data point based on PR32037, but caching does good things for compile-time on that example. Trunk r298514 compiled release on macOS running on Haswell 4GHz: $ time ./opt -O2 row_common.bc -S -o /dev/null user 0m0.302s user 0m0.300s user 0m0.296s user 0m0.299s user 0m0.296s With your patch applied: user...

...e a difference too (without this part, or without the KnownBits part I get results below 1%, which are not reported as regressions/improvements). Personally I think caching results of KnownBits is a good idea, and should probably help O3 compile time (and obviously the cases from bug reports, like PR32037). But I also think that the way we're currently doing combining/canonicalization is unnecessary complicated. Do we really need to try canonicalizing all of these patterns? What happens if we don't? Has anyone tried replace some of the InstCombine invocations with InstSimplify? Do we have a...

> On Mar 17, 2017, at 6:12 PM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls