[PATCH] D58675: [clang] Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps

[Anton Afanasyev via Phabricator via llvm-commits]

anton-afanasyev marked 3 inline comments as done.
anton-afanasyev 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));
----------------
lebedev.ri wrote:
> anton-afanasyev wrote:
> > lebedev.ri wrote:
> > > 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}
> > "Mostly coincides" here means "identical" I believe, the difference is auxiliary stuff.
> > Please look at `clang::EmitBackendOutput()`, `"Backend"` timer is outer for `"codegen"` one.
> Then we are talking about different things using the same name.
> There are two distinct codegen steps:
> 1. clang AST -> LLVM IR codegen
> (after that, all the opt passes run)
> 2. LLVM IR -> final assembly. This happens after all the opt middle-end passes.
> 
> Those are *different* codegen's.
Yes, and step 1 is named as "CodeGen Function" whereas step 2 is named just "Backend".


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58675/new/

https://reviews.llvm.org/D58675