Hi, While doing various profiling runs of llc, it's easy to notice that some wall-clock time is not accounted for by -time-passes (e.g. only 7 out of 9.2 seconds for compiling gcc). Some of the "lost" time is in reading the bitcode file (~ 1 sec). When reading textual IR, its parsing actually takes almost as much time as doing the actual -O0 compilation! I think it would be useful if we could ask the tools to time how long IR reading took (perhaps expanding it later to break down materialization, etc). In addition to significantly minimizing un-accounted time, this can facilitate future attempts to optimize the IR reading code. Any objections/insights? If this is deemed useful, there's the question of implementation. 1. Piggybacking on time-passes (like DWARF dumping does) is probably not the "right thing to do", and hard to implement too since some tools like llvm-diff don't even link in the pass infrastructure (which defines the required globals). 2. Creating a separate flag is feasible, but IRReader is currently header-only. So an implementation file has to be created to hold the actual flag. 3. Any other ideas? Eli
Ping? On Thu, Feb 28, 2013 at 12:59 PM, Eli Bendersky <eliben at google.com> wrote:> Hi, > > While doing various profiling runs of llc, it's easy to notice that > some wall-clock time is not accounted for by -time-passes (e.g. only 7 > out of 9.2 seconds for compiling gcc). Some of the "lost" time is in > reading the bitcode file (~ 1 sec). When reading textual IR, its > parsing actually takes almost as much time as doing the actual -O0 > compilation! > > I think it would be useful if we could ask the tools to time how long > IR reading took (perhaps expanding it later to break down > materialization, etc). In addition to significantly minimizing > un-accounted time, this can facilitate future attempts to optimize the > IR reading code. Any objections/insights? > > If this is deemed useful, there's the question of implementation. > > 1. Piggybacking on time-passes (like DWARF dumping does) is probably > not the "right thing to do", and hard to implement too since some > tools like llvm-diff don't even link in the pass infrastructure (which > defines the required globals). > 2. Creating a separate flag is feasible, but IRReader is currently > header-only. So an implementation file has to be created to hold the > actual flag. > 3. Any other ideas? > > Eli
I think this is definitely useful and #2 makes sense to me. Evan On Mar 1, 2013, at 1:25 PM, Eli Bendersky <eliben at google.com> wrote:> Ping? > > On Thu, Feb 28, 2013 at 12:59 PM, Eli Bendersky <eliben at google.com> wrote: >> Hi, >> >> While doing various profiling runs of llc, it's easy to notice that >> some wall-clock time is not accounted for by -time-passes (e.g. only 7 >> out of 9.2 seconds for compiling gcc). Some of the "lost" time is in >> reading the bitcode file (~ 1 sec). When reading textual IR, its >> parsing actually takes almost as much time as doing the actual -O0 >> compilation! >> >> I think it would be useful if we could ask the tools to time how long >> IR reading took (perhaps expanding it later to break down >> materialization, etc). In addition to significantly minimizing >> un-accounted time, this can facilitate future attempts to optimize the >> IR reading code. Any objections/insights? >> >> If this is deemed useful, there's the question of implementation. >> >> 1. Piggybacking on time-passes (like DWARF dumping does) is probably >> not the "right thing to do", and hard to implement too since some >> tools like llvm-diff don't even link in the pass infrastructure (which >> defines the required globals). >> 2. Creating a separate flag is feasible, but IRReader is currently >> header-only. So an implementation file has to be created to hold the >> actual flag. >> 3. Any other ideas? >> >> Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev