Teresa, Yes, I didn't take enhancements in google branches into account while porting this patch. In light of these comments, I withdraw this patch and will wait for your patch. Once your patch is in, I will update this patch for regular dumps.
To answer your other question, yes, the new dump infrastructure can dump to either dump file or opt-info streams (or both) depending upon dump_flags. If the dump_flags contain TDF_* flags then the dump happens on regular dump files, if dump_flags contain MSG_* flags then the dump happens on opt-info stream. Thanks, Sharad On Thu, Dec 13, 2012 at 9:37 PM, Teresa Johnson <tejohn...@google.com> wrote: > 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
