[PATCH] D58675: [clang] Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps
Roman Lebedev via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Sep 24 08:21:04 PDT 2019
lebedev.ri added inline comments.
================
Comment at: cfe/trunk/lib/CodeGen/BackendUtil.cpp:1426-1431
EmitAssemblyHelper AsmHelper(Diags, HeaderOpts, CGOpts, TOpts, LOpts, M);
if (CGOpts.ExperimentalNewPassManager)
AsmHelper.EmitAssemblyWithNewPassManager(Action, std::move(OS));
else
AsmHelper.EmitAssembly(Action, std::move(OS));
----------------
anton-afanasyev wrote:
> anton-afanasyev wrote:
> > lebedev.ri wrote:
> > > This isn't covered by any timer; if you look in `BackendUtil.cpp`,
> > > `EmitAssemblyHelper` actually has `CodeGenerationTime("codegen", "Code Generation Time")` timer.
> > Thanks, I'm to add it.
> Hmm, I've figured out this isn't needed: such new timer mostly coincides with "Backend" timer (above). Legacy `Timer CodeGenerationTime(...)` is bad example of doing right timing.
"Mostly coincides" may not be the best way to approach fine-grained timings, i think? :)
I have noticed this because when i looked at the produced time flame graph,
there's large section in the end that is covered only by `"Backend"` timer,
but nothing else. Now, i'm not going to say whether or not that extra section
should or should not be within `"Backend"` timer, but it certainly should *also*
be within `"codegen"` timer. Or is there no codegen time spent there?
{F10062322}
{F10062316}
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D58675/new/
https://reviews.llvm.org/D58675
More information about the cfe-commits
mailing list