>
>
> *Ideas on how to improve the backend situation:*
> *- Let FPPassManager::runOnFunction() call*
> *if (ProfileTime)*
> *llvm::timeTraceProfilerBegin("RunPass", FP->getPassName());*
> * for each pass so that it's visible which path the time goes into*
>
In my tests (which I admitt
I haven't tried -ftime-report here. I tried it in the past and found it
difficult to interpret, as the blog post you link to correctly says :) I
thought -ftime-trace was supposed to be more usable, so I figured I'd try
that instead. And for frontend stuff, it does look much better!
Ideas on how to
Hi Nico,
yes, you are right, current implementation is mostly focused on frontend.
Yes, I can impove BE time output after getting feedback like yours one. Do
you need detailed info about BE passes times? Btw, did you try
-ftime-report option? It could give you detailed info on BE passes
bottlenecks
I tried using this to see why X86ISelLowering.cpp takes so long to build on
my system. The output json produced by this flag is at
http://s000.tinyupload.com/?file_id=00019982161870973700
It looks like this produces lots of useful information for frontend time,
but in this case most time is spent
Author: anton-afanasyev
Date: Sat Mar 30 01:42:48 2019
New Revision: 357340
URL: http://llvm.org/viewvc/llvm-project?rev=357340&view=rev
Log:
Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing`
compatible JSON profiling output dumps.
This change adds hierarchical "time tr
