On Thu, Dec 13, 2012 at 8:58 PM, Xinliang David Li <davi...@google.com> wrote: > A couple of comments: > > 1) please dump with source location if possible. What is the use of > the information if there is no line number
The google branches have the code to identify a source location of the loop, and a similar message to the one proposed below (which uses the inform() interface on the google branches). I have a trunk patch ready to submit with this ported to the new dumping infrastructure, which I was going to submit after Sharad's patch. Sharad, do you want me to submit that one first, then it can be leveraged if you want to extend the messages? But I agree with David in that I think the bulk of these types of messages should stay in the dump file and not be emitted by -fopt-info because they are too verbose and low-level. Can the new dumping infrastructure be used to just dump to the dump file and not via -fopt-info? Teresa > 2) Please do not use the existing dump report -- Loop 1,2,3 etc means > nothing to user > 3) The optimization report should be standardized with some template > (similar to informational notes): > > file line:column note: <xxxx> is <yyyy>ed <additional information) > > where xxxx is a source construct such as a loop, a branch, a > function etc, while yyyy is the transformation such as 'vectorized', > 'unrolled', 'peeled', 'if converted', 'hoisted' etc. Additional > information can be something to describe more about the transformation > and the source construct. For instance, unrolled N times, unrolled > completely, and profile information of the loop (entry count, > average trip count etc). The addtitional information needs to be > concise. Please do *not* dump with verbosity as you proposed > (including the size, induction variable folding, exit condition > elimination etc). > > 4) the existing dump (into the dump file) can be changed to use the > same dump format above > 5) For loop unroll/peeling, the dumping code can be refactorized using > one report function -- see the code in google branch > > 6) do not forget the tree level unroller. > > David > > On Thu, Dec 13, 2012 at 6:15 PM, Sharad Singhai <sing...@google.com> wrote: >> Hi, >> >> As per discussion in http://gcc.gnu.org/ml/gcc/2012-12/msg00056.html, >> the attached patch updates loop unroll passes to use new dump >> infrastructure. >> >> This patch filters relevant dump messages into the following >> three categories >> >> - optimized: an optimization was successfully applied >> - missed: an optimization was missed due to the described reason >> - note: other relevant/detailed info during optimization. For example, >> loop unrolling computes the loop bounds and size. >> >> Two sample outputs from one of the gcc tests (gcc.dg/unroll_1.c) are below. >> >> Sample 1 >> -------------- info about optimized loops via >> "-fopt-info-loop-optimized" ------- >> $ gcc gcc.dg/unroll_1.c -fno-diagnostics-show-caret -O2 -S >> -fdump-rtl-loop2_unroll -funroll-loops -fopt-info-loop-optimized >> >> Unrolled loop 1 completely (duplicated 2 times). >> Exit condition of peeled iterations was eliminated. >> Last iteration exit edge was proved true. >> Unrolled loop 1 completely (duplicated 2 times). >> Exit condition of peeled iterations was eliminated. >> Last iteration exit edge was proved true. >> -------------------------------- >> >> Sample 2: >> --- All available loop optimization info, i.e., optimized+missed+note >> via "-fopt-info-loop" --- >> $ gcc gcc.dg/unroll_1.c -fno-diagnostics-show-caret -O2 -S >> -fdump-rtl-loop2_unroll -funroll-loops -fopt-info-loop >> >> Loop 1 iterates 2 times. >> Loop 1 iterates at most 2 times. >> Estimating sizes for loop 1 >> BB: 4, after_exit: 0 >> size: 2 if (i_1 <= 1) >> Exit condition will be eliminated in peeled copies. >> BB: 3, after_exit: 1 >> size: 1 _5 = b[i_1]; >> size: 1 _6 = _5 + 1; >> size: 1 a[i_1] = _6; >> size: 1 i_8 = i_1 + 1; >> Induction variable computation will be folded away. >> size: 6-3, last_iteration: 2-0 >> Loop size: 6 >> Estimated size after unrolling: 5 >> Unrolled loop 1 completely (duplicated 2 times). >> Exit condition of peeled iterations was eliminated. >> Last iteration exit edge was proved true. >> Forced exit to be taken: if (1 == 0) >> Loop 1 iterates 2 times. >> Loop 1 iterates at most 2 times. >> Estimating sizes for loop 1 >> BB: 4, after_exit: 0 >> size: 2 if (i_1 <= 1) >> Exit condition will be eliminated in peeled copies. >> BB: 3, after_exit: 1 >> size: 1 _4 = b[i_1]; >> size: 1 _5 = _4 + 1; >> size: 1 a[i_1] = _5; >> size: 1 i_7 = i_1 + 1; >> Induction variable computation will be folded away. >> size: 6-3, last_iteration: 2-0 >> Loop size: 6 >> Estimated size after unrolling: 5 >> Unrolled loop 1 completely (duplicated 2 times). >> Exit condition of peeled iterations was eliminated. >> Last iteration exit edge was proved true. >> Forced exit to be taken: if (1 == 0) >> -------------------------------- >> >> I would like to mention that this information is perhaps too verbose >> and the the source location of optimized loops is not displayed. I can >> add source line info (and fix up corresponding tests) if needed. But >> right now I wanted to maintain current dump format faithfully. Perhaps >> the format can be tweaked for better readability. >> >> Note that all information dumped in response to -fopt-info is also >> present in regular dump file(s) when corresponding dumps are >> enabled. Thus in above examples, the loop optimization info is also >> present in *.loop2_unroll dump file since the command line specified a >> dump file via "-fdump-rtl-loop2_unroll" in addition to -fopt-info. >> >> (As a side note, while doing the conversion, I found that the MSG_* >> dump flags are unwieldy when used in conjunction with other >> flags. Perhaps these flags should be renamed/shortened. I propose the >> following >> MSG_MISSED_OPTIMIZATION ==> MSG_MISSED >> MSG_OPTIMIZED_LOCATIONS ==> MSG_OPTIMIZED >> But that is pure renaming and can be done separately.) >> >> I have bootstrapped and tested this patch on x86_64 and found no new >> failures. Okay for trunk? >> >> Thanks, >> Sharad -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413