Re: [PATCH] Use new dump scheme for loop unroll passes

[Sharad Singhai <singhai at google dot com>]

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 <tejohnson@google.com> wrote:
> 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