[FnSpecialization] Enable function specialization of call chains

[bababuck]

Currently, we don't optimize function-specialize cases like the following:

int foo(int a) {
  return a + 1;
}

int bar(int a) {
  return foo(a);
}

int main() {
  return bar(3);
}

because when specializing for the 3 passed to bar(), the value isn't propagated into foo() to gauge benefit from specializing foo() as well. With this patch, the optimized code would be:

int foo.specialized.1() {
  return 4;
}

int bar.specialized.2() {
  return foo.specialized.1();
}

int main() {
  return bar.specialized.2();
}

This patch required a fair amount of refactoring before making my changes. That refactoring was done as a series of commits before the main changes for this patch. I'm assuming that (if accepted) this should get merged in as a series of MRs.

The series of commits (x/6) all belong together since they are the same functional change, but I left them as separate commits for easier reading.

At a high level, each Spec element can have SubSpecs which are functions that it forwards its constant argument(s) to and should be specialized along with it. In the above exampled, the Spec for bar(3) would have a SubSpec for foo(3).

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[labrinea]

when specializing for the 3 passed to bar(), the value isn't propagated into foo() to gauge benefit from specializing foo() as well

The function InstCostVisitor::visitCallBase tries to compute benefit from constant folding if possible. In this example it cannot constant fold foo(3) while propagating the constant inside bar's body. However given a small enough codesize threshold this example gets specialized: https://godbolt.org/z/dvfMov9WM

[bababuck]

when specializing for the 3 passed to bar(), the value isn't propagated into foo() to gauge benefit from specializing foo() as well

The function InstCostVisitor::visitCallBase tries to compute benefit from constant folding if possible. In this example it cannot constant fold foo(3) while propagating the constant inside bar's body. However given a small enough codesize threshold this example gets specialized: https://godbolt.org/z/dvfMov9WM

Agreed, thank you for the correction! My understanding is that visitCallBase, which calls ConstantFolding.cpp::ConstandFoldCall which to my understanding is targeted at intrinsics and library calls (please correct me if I'm wrong).

The example on Godbolt only specializes on the current upstream due to some funny behavior of the function specializer, see #164867 (this change is included in this MR as well, I have begun splitting off small chunks that can stand on their own).

[labrinea]

I briefly looked at the patch series and I am not convinced it's the right approach. Perhaps it's best to handle non constant foldable calls in the instruction cost visitor separately, similarly to branches and switches which are not folded to a constant. I mean to compute the profitability of specializing that call instead of folding it. But then all this adds compile time complexity which I am not sure it is worth it.

[bababuck]

Sorry for the slow response, and thanks for taking the time to engage.

Perhaps it's best to handle non constant foldable calls in the instruction cost visitor separately, similarly to branches and switches which are not folded to a constant.

I think that is a competitive approach, here were my pro's/con's between the two approaches:
Pro's of approach in patch:

• Able to handle indirect function calls that are constants. Since currently we visit each instruction one argument as a time, the second approach would require additional caching logic to handle this.
• Can handle chained specialization in a single run() loop, doesn't run the risk of specializing the first layer and not the second (in the case where max iterations is hit, or maximum code-size is reached.) At least if my understanding is correct, the cost metric would allow the outer function to specialize due to the savings of the inner function. Then in the next iteration, the inner function would specialize.

Pro's of the approach you suggested:

• Much cleaner implementation, only need to extend a single area of the code

But then all this adds compile time complexity which I am not sure it is worth it.

We were looking into this for a particular case in x264 which we wanted to optimize, but I can collect data on how this code behaves on other workloads.