Move -ftime-trace-granularity option to frontend options. Without patch
this option is showed up in the help for any tool that links libSupport.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 35584 Build 35583: arc lint + arc unit
Event Timeline
clang/docs/ClangCommandLineReference.rst | ||
---|---|---|
1943–1953 | While there add a description to -ftime-report and document how they are different? | |
clang/include/clang/Driver/Options.td | ||
1759–1765 | While there add description to ftime_report and document their difference? | |
llvm/lib/Support/TimeProfiler.cpp | ||
26–27 | Can TimeTraceGranularity perhaps be stored in TimeTraceProfilerInstance? |
clang/docs/ClangCommandLineReference.rst | ||
---|---|---|
1951 | is there any possibility of wanting a granularity <1ms in the future? This sets up a backward-compatibility trap if so. | |
clang/lib/Frontend/CompilerInvocation.cpp | ||
1772 | You've got the default repeated here. Is it possible to set this conditionally here, or use the existing value as default like Opts.TTG = getLastArgIntValue(Args, OPT_fttg_EQ, Opts.TTG, Diags) | |
llvm/lib/Support/TimeProfiler.cpp | ||
27 | why does this have a default value? It shouldn't be possible to use it without overwriting it, IIUC | |
27 | static |
Looks ok
clang/docs/ClangCommandLineReference.rst | ||
---|---|---|
1943–1953 | I mean, state that one is chrome json trace and another is console table output |
clang/docs/ClangCommandLineReference.rst | ||
---|---|---|
1943–1953 | The difference is actually deeper at the moment. -ftime-report output is buggy, short and uninformative (as noted by @aras-p in his blog post http://aras-p.info/blog/2019/01/12/Investigating-compile-times-and-Clang-ftime-report/). I would like just to remove -ftime-report option as obsolete and unsupported. |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
1772 | Ok, done. |
clang/docs/ClangCommandLineReference.rst | ||
---|---|---|
1951 | To be more correct, this granularity value (-ftime-trace-granularity=0) will work after this old patch https://reviews.llvm.org/D63325 is commited. |
is there any possibility of wanting a granularity <1ms in the future? This sets up a backward-compatibility trap if so.