On Fri, Apr 04, 2025 at 07:21:47AM +0300, Eldar Kusdavletov wrote: > Thanks. I’ve submitted a more concrete version of the proposal — attaching it > here. > > I’ve taken a brief look at Clang’s implementation, but the idea isn’t to > follow > it exactly — rather, to provide a similar kind of trace-based visualization in > a way that fits naturally into GCC’s internals. > > The plan is to build on top of the existing timevar infrastructure (as you > said), but shift focus toward a higher-level view: breaking down time spent on > a per-function basis, showing how different compiler passes nest and > contribute > to the overall time, and exporting that as a Chrome trace (JSON). > > Let me know if anything still feels too vague or needs clarification — happy > to > adjust. Really appreciate your thoughts!
Thanks for the write up. It looks a lot better. For middle/backend optimization the pass manager already works on functions and measures the timevars this way. The information is just currently all aggregated. It shouldn't be that hard to output this per function. You may need some mapping from low level passes to higher level operations though (perhaps that is what you meant with aggregation layer) I don't think it would be easy to go below functions at this level, it would require lots of changes in the individual passes, which would be a very large project by itself. But then there is also slowness in the frontend, like declaration processing, macro and template expansion etc. These would be also interesting to account, but there is no pass manager at this level so you would need to add a much smaller number of custom hooks. This is easier because there isn't a large number of passes there At that level you (and likely should) account below functions to individual statements and declarations. You may also need to limit yourself to specific languages (e.g. C/C++ only) I would separate these two cases in the project plan because they are quite different. -Andi