Added long running commands runtime to log files.

[annapetrosyan26]

Added logging of the runtime and peak memory for the following commands:

• global_place
• rtl_macro_placer
• repair_design
• repair_timing
• global_route
• detailed_route

Updated the regression tests diff checking to ignore runtime lines.

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[annapetrosyan26]

@stefanottili @rovinski @oharboe @maliberty @QuantamHD this PR addresses the #5003 issue. Could you please take a look? The changes have been locally tested.

[stefanottili]

Would it be possible to put the name of the command in the same line ? The whole idea was to be able to grep for a keyword to easily get runtime info out of the verbose log file.

[maliberty]

Also, there was a request to make this non-default option so that logs/reports don't become any more non-idempotent than they already are.

I disagreed then and still do. The goal is to have an informative log file by default. If you want to give up information to get idempotency that should be the non-default option.

[oharboe]

Also, there was a request to make this non-default option so that logs/reports don't become any more non-idempotent than they already are.

I disagreed then and still do. The goal is to have an informative log file by default. If you want to give up information to get idempotency that should be the non-default option.

I wanted to mention it, because it came up last time.

I do prefer this sort of information in logs by default and I don't know bazel well enough to understand why or how non-idempotent log artifacts cause a problem or if they are just an eyesore of sorts. I haven't observed any problems as such. Non-idempotent logs don't surprise me and isn't a problem for me. Looking forward to an explanation of the issue here for such build systems. bazel is one example, there are other... Certainly with build times of 24 hours, artifacts are required, ORFS alone doesn't cut it.

[annapetrosyan26]

Would it be possible to put the name of the command in the same line ? The whole idea was to be able to grep for a keyword to easily get runtime info out of the verbose log file.

We can put the name of the command in the same line.

[oharboe]

Could you show some example output in this PR after the next update?

[annapetrosyan26]

Could you show some example output in this PR after the next update?

The log file should contain an information like the example below: repair_design: runtime = 0.000545613 (seconds), rsz start = 2197.27 (MB), vsz start = 4031.35 (MB), rsz peak = 2197.27 (MB), vsz peak = 4031.35 (MB). Will this work?

[oharboe]

Could you show some example output in this PR after the next update?

The log file should contain an information like the example below: repair_design: runtime = 0.000545613 (seconds), rsz start = 2197.27 (MB), vsz start = 4031.35 (MB), rsz peak = 2197.27 (MB), vsz peak = 4031.35 (MB). Will this work?

• Round off to integer seconds & megabytes.
• Now I have to mentally do the math of peak - start, which is the information I care about. So the log line could do this math for me. net usage rsz = 1234/MB, vsz 12552/MB, peak rsz = 13534/MB, vsz 1552/MB
• If this log line line can be squeezed into 80 chars while being legible, that's a boon...

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[stefanottili]

It would be nice to have one common prefix that one can grep for.

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[annapetrosyan26]

@maliberty the appropriate changes have been made. Could you please review them?