On Oct 13, 2022, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Oct 11, 2022 at 3:33 PM Alexandre Oliva <ol...@adacore.com> wrote: >> >> On Oct 11, 2022, Richard Biener <richard.guent...@gmail.com> wrote: >> >> > On Tue, Oct 11, 2022 at 1:57 PM Alexandre Oliva <ol...@adacore.com> wrote: >> >> >> >> On Oct 10, 2022, Richard Biener <richard.guent...@gmail.com> wrote: >> >> >> >> > As noted in the Cauldron Discussion I think you should do all >> >> > instrumentation post-IPA only to simplify your life not needing to >> >> > handle inlining of instrumentation >> >> >> >> I looked a bit into that after the Cauldron, and recalled why I wanted >> >> to instrument before inlining: in the case of internal strub, that >> >> introduces a wrapper, it's desirable to be able to inline the wrapper. >> >> > I think if the wrapper is created at IPA time it is also available for >> > IPA inlining. >> >> Yeah, but now I'm not sure what you're suggesting. The wrapper is >> instrumentation, and requires instrumentation of the wrapped >> counterpart, so that can't be post-IPA.
> IPA folks can probably explain better but there's IPA (local) > analysis, IPA (global) propagation > and IPA (local) code generation. I think we're miscommunicating. None of these are post-IPA, they're all part of IPA. At first, you'd suggested instrumentation to be made post-IPA, to avoid the trouble of inlining instrumentation. But we *do* want to inline the instrumentation. Now you seem to be suggesting a major revamp of the implementation to integrate it into IPA, rather than post-IPA, while I keep on trying to reconcile that with the initial recommendation of moving it post-IPA. Have you dropped the initial recommendation, and moved on to an unrelated recommendation? If so, I can stop trying to reconcile the unrelated recommendations as if they were related, and focus on the newer one alone. My reasons to not want to integrate strub tightly into IPA infrastructure was that there was no perceived benefit from a tighter integration, and I wasn't sure the feature would be welcome, so I designed something that could be added in a very standalone way, maybe even as a plugin. Maybe there is interest and this decoupling could be reduced, but there'd have to be very compelling reasons to justify undergoing such major reengineering. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
