This allows for passes to nest additional timing scopes by
using the new createTimingScope method. This will allow
for pass authors to inject more valuable timing information
into their passes when necessary, which is valuable when
debugging expensive passes, or just for tracking important
passes in general. Timing scopes are a no-op when timing
is not enabled.
Details
- Reviewers
mehdi_amini
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
That is awesome! I was thinking about rebasing the Timing on top of the Action framework this after I publish it (soonish). Can we table this for a couple of weeks so we can check how we converge this nicely?
My current thought is that this is a great direction to be able to use timing for more than passes, the ability to delimitate arbitrary sections of code to trace is a common need (showcased by people using Tracy for example).
Something that seems not orthogonal right now in the way timing is setup is that this is very much anchored to the Pass infrastructure, but other than historical reason I am not sure why?
Seems like this could be decoupled from the pass infra, and attached to the Context instead for example. That would give the possibility to add timers anywhere there is an IR construct: if I'm in a utility method and I want to instrument it temporarily I likely don't want to thread a callback to createTimingScope through multiple layers of API so that I can ultimately pass it in from all the passes that transitively use this utility.
Have you already thought about that?