arsenm wrote: > I'm somewhat skeptical that this really fits into llvm-reduce. Unless we make > the heuristic so narrow that it's likely useless in most cases, we'll hit > cases where inlining will reduce the size of the reduction.
Most of the time I'd prefer increased IR size for reduced codegen complexity, which is what you get with inlining. The main driver is still checking the net result with getComplexityScore (although I'm not sure how well that really works, it seems to be trying to check every possible reduced field but misses many of them). On the examples I've tried so far, it's basically produced the same result as running a single pass in the interestingness test (it just takes longer to run). More than a few times I've gotten complaints (or seen crappy reduction output in tests added to patches) from reducing running the whole pipeline in the interestingness script. The goal is to get a better result in the case where someone didn't know to get to the minimal pipeline reproducer. Plus the pipeline reduction isn't going to artificially inline at an arbitrary point; it's still bound by optimizing profitability logic. https://github.com/llvm/llvm-project/pull/134223 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
