On Thursday, April 3rd, 2025 at 10:45 PM, Andi Kleen <a...@firstfloor.org> wrote:
> > > 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 Just to add my two cents here, I think this would be an excellent addition and was surprised when I found that GCC was missing this feature in the past. It will also be really useful to be able to compare the two compilers even if it's not directly apples to apples. Alex
