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

Reply via email to