Implement MT Analysis Tracing

[Rexicon226]

EDIT: almost forgot to credit the original creator of the code, @SpexGuy! Thanks!

This PR implements creating Spall time traces through the added --debug-timing option.

Why is this useful?

As we focus more on optimization in the Zig compiler, and more importantly parallelization, it becomes nice to have an easy-to-use tracing system that works well with our multi-threading design. The current option for this is Tracy, which is more focused on tracing the specific functions inside the compiler and frankly is not easy to use.

This offers a much easier-to-use alternative that's focused on the analysis flow inside of the compiler, instead of tracing specific functions.

• All you need to view the output is a browser, using a website such as perfetto, gravity moth, or chrome://tracing.
• Doesn't require linking libc, so it can be used on a purely self-hosted build of the compiler.

If you need detailed traces of the internal function call stack, Tracy is the go-to.

Examples:

This image is a bit zoomed out, but I hope it provides the basic idea of what an output trace looks like. This is using @jacobly0's multi-threaded codegen branch, so there are 33 total TIDs. Each time range is the start to the end of a decl/function being analyzed or codegen-ed.

Follow-up questions

• Should this functionality be hidden behind a dev "Env"?

As I see it, the pro is that this internal Zig debug flag couldn't be used in distributed builds. The con is that if someone wanted to trace for example the LLVM backend, they'd need to manually modify dev.zig.

• Any better names for the flag?

I choose this one because it's a debug, timing. Always open to better suggestions.

• Should there be build.zig support for the flag?

Also a pro and con question. Pro is that we could potentially revive gotta-go-fast and make the generation of such graphs automatic. Con is that again, it's a debug flag for internal use.

[andrewrk]

Is this intended to be useful for developers of the compiler, or users of the compiler?

[Rexicon226]

Developers of the compiler, although if users were to build a compiler with this enabled, I guess they could benefit from the analysis breakdown. Obviously, this is tracing functions inside of the Zig compiler, so this wouldn't help much in terms of LLVM codegen, but maybe it could give some insight into long-running comptime analysis?

[kcbanner]

Is this intended to be useful for developers of the compiler, or users of the compiler?

I could see this being useful to answer the question: "why has my project slowly gotten slower and slower to compile". Perhaps I could then narrow down which code is slow to analyze and possible move it to a library. This is something I've been struggling with on a project, where my iteration times have been getting slower, but I'm not sure where the time is actually being spent.

[andrewrk]

I could certainly see it being useful in that case, but I don't see it as a satisfactory answer to the question because it's more effort than should be necessary for Zig users.

[andrewrk]

This pull request is not ready for review because:

• It has conflicts that must be resolved via rebasing against latest origin/master.
• It is not passing the CI tests.

Since we have moved development to Codeberg, please open your pull request there if you would like to continue these efforts.