This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Use new dump scheme for loop unroll passes
On Thu, Dec 13, 2012 at 8:58 PM, Xinliang David Li <davidxl@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 <singhai@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 | tejohnson@google.com | 408-460-2413