>
>
> *Ideas on how to improve the backend situation:*
> *- Let FPPassManager::runOnFunction() call*
> * if (ProfileTime)*
> * llvm::timeTraceProfilerBegin("RunPass", FP->getPassName());*
> * for each pass so that it's visible which path the time goes into*
>
In my tests (which I admittedly only tried for "slow to compile things" at
work), even the one single timer scope per function was already "not
terribly useful" -- most of our code ends up being lots of functions, but
at that point there's no easy way to e.g. group them by
class/namespace/etc. Digging deep into individual passes inside each
function might be useful for very slow to compile functions, but I haven't
ran into that yet -- that's the only reason why I haven't added the scopes.
*- Have a thing _somewhere_ (in clang? in chrome's about:tracing? a
> standalone tool?) that makes it possible to look at a flame graph view of
> the trace. A flame graph is a trace that's sorted by call stack, not by
> time, so that all the same stacks are next to each other, which makes it
> easy to see things like "30% of time is spent in function X" – together
> with the first suggestion it'd make the slowest path visible.*
>
The excellent https://www.speedscope.app/ can already do that for any
Chrome Tracing profile file -- just switch to "Left Heavy" view.
--
Aras Pranckevičius
work: https://unity3d.com
home: https://aras-p.info
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
