On Thu, Jul 14, 2022 at 3:42 PM Erick Ochoa <eoc...@gcc.gnu.org> wrote: > > Hi Richard, > > >> > >> > So instead of wrapping the function why not transform the original function >> > to have a prologue doing a runtime check for the compile-time specialized >> > versions and perform tail-calls to them? >> > >> > What I'm missing is who would call mul_test_param in your case? > > > The idea is that all callsites to mul may call instead mul_test_param or only > those for which there is no known compile time constant. If we had some more > information about the distribution of the parameter values at runtime, then > we could even choose not to use the wrapper. > >> >> Following your variant more closely would be doing value profiling >> of function parameters and then "speculative IPA-CP". > > > Yes, the idea of doing value profiling on function parameters certainly fits > this very well. I refrained from calling it "speculative IPA-CP" and instead > called it specialization with a parameter test but the idea I think is the > same. However, the main difference between "speculative IPA-CP" and this idea > is that (if I understand correctly how speculative IPA-CP works) is that > instead of changing the callsite C to the following version: > > C: mul_test_param (c, d); > > speculative IPA-CP will have the transformation > > C: if (a == 2) mul.constprop1 (a) > else if (a == 4) mul.constprop2 (a) > else mul (a, b) > > Which depending on how many non compile-time constant callsites there are, > will increase the size of the binary. That's why I prefer the wrapper around > the function. But this would be essentially inlining the wrapper.
With a value-profile it would be per call site and IPA-CP can use that to direct the cloning. I'm not sure how many values a value histogram can track reliably here. > > As of now, the only "speculative IPA-CP" that I've seen is the speculation on > the target of the indirect edge. I could look into exactly how this mechanism > works to try to instead speculate on an arbitrary argument. Do you think that > would be a good first step instead of creating a wrapper and replacing the > edges to the wrapper?
