https://github.com/nikic commented:
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. The proper way to do a reduction that involves inlining is to use reduce_pipeline.py to cut down the full optimization pipeline to a sub-pipeline on a new input. Unfortunately, this is a separate tool from llvm-reduce, and architecturally, it doesn't always quite do what we really want (which may involve running the full CGSCC pipeline for some functions but not others, rather than running a subset of the pipeline for all functions). Pipeline reduction is something that bugpoint used to be able to do, but kind of became a second class citizen in the llvm-reduce world -- I think that's the real problem we need to address in this context. 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
