llvm-reduce: Add new pass to inline call sites

[arsenm]

Added a primitive heuristic to avoid blowing up the code size
which could use more thought.

This helps cleanup some basic examples I've been looking at where
there is a worse result when just running a bug through the full
optimization pipeline vs. running just a single pass at the point
of failure.

[arsenm]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• llvm-reduce: Add new pass to inline call sites #134223 👈 (View in Graphite)
• InlineFunction: Split inlining into predicate and apply functions #134213
• CloneFunction: Do not delete blocks with address taken #134209
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[nikic]

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 increase 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.

[arsenm]

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.

[regehr]

in C-Reduce we had an inliner. it (and other transformations) routinely increased the code size, but in general these were worthwhile since the eventual reduced test ended up smaller than it otherwise would have.

there's still a legitimate policy question here, which is whether people running reducers want things like inlining to be performed, or whether they're just purely looking to get the irrelevant junk stripped out of test cases. I went with the former thing and generally was happy with the outcomes. ymmv...

[regehr]

so anyway, as a reasonably heavy llvm-reduce user, I'd be happy to see this merged, but I don't have strong feelings if this ends up being the wrong thing here.

[nickdesaulniers]

I used creduce, cvise, and llvm-reduce a lot; I think inlining was the way to go.

[nickdesaulniers]

Would you also filter with isInlineViable or no?

[arsenm]

No, that mostly filters cases that are incorrect to inline but we don't care about that

[aeubanks]

perhaps a heuristic of reducing the total number of inlinable calls, i.e. the function being inlined cannot have any inlinable calls, would be good for not letting this run too much