On January 15, 2021 5:16:40 PM GMT+01:00, Qing Zhao <qing.z...@oracle.com>
wrote:
>
>
>> On Jan 15, 2021, at 2:11 AM, Richard Biener <rguent...@suse.de>
>wrote:
>>
>>
>>
>> On Thu, 14 Jan 2021, Qing Zhao wrote:
>>
>>> Hi,
>>> More data on code size and compilation time with CPU2017:
>>> ********Compilation time data: the numbers are the slowdown
>against the
>>> default “no”:
>>> benchmarks A/no D/no
>>>
>>> 500.perlbench_r 5.19% 1.95%
>>> 502.gcc_r 0.46% -0.23%
>>> 505.mcf_r 0.00% 0.00%
>>> 520.omnetpp_r 0.85% 0.00%
>>> 523.xalancbmk_r 0.79% -0.40%
>>> 525.x264_r -4.48% 0.00%
>>> 531.deepsjeng_r 16.67% 16.67%
>>> 541.leela_r 0.00% 0.00%
>>> 557.xz_r 0.00% 0.00%
>>>
>>> 507.cactuBSSN_r 1.16% 0.58%
>>> 508.namd_r 9.62% 8.65%
>>> 510.parest_r 0.48% 1.19%
>>> 511.povray_r 3.70% 3.70%
>>> 519.lbm_r 0.00% 0.00%
>>> 521.wrf_r 0.05% 0.02%
>>> 526.blender_r 0.33% 1.32%
>>> 527.cam4_r -0.93% -0.93%
>>> 538.imagick_r 1.32% 3.95%
>>> 544.nab_r 0.00% 0.00%
>>> From the above data, looks like that the compilation time impact
>>> from implementation A and D are almost the same.
>>> *******code size data: the numbers are the code size increase
>against the
>>> default “no”:
>>> benchmarks A/no D/no
>>>
>>> 500.perlbench_r 2.84% 0.34%
>>> 502.gcc_r 2.59% 0.35%
>>> 505.mcf_r 3.55% 0.39%
>>> 520.omnetpp_r 0.54% 0.03%
>>> 523.xalancbmk_r 0.36% 0.39%
>>> 525.x264_r 1.39% 0.13%
>>> 531.deepsjeng_r 2.15% -1.12%
>>> 541.leela_r 0.50% -0.20%
>>> 557.xz_r 0.31% 0.13%
>>>
>>> 507.cactuBSSN_r 5.00% -0.01%
>>> 508.namd_r 3.64% -0.07%
>>> 510.parest_r 1.12% 0.33%
>>> 511.povray_r 4.18% 1.16%
>>> 519.lbm_r 8.83% 6.44%
>>> 521.wrf_r 0.08% 0.02%
>>> 526.blender_r 1.63% 0.45%
>>> 527.cam4_r 0.16% 0.06%
>>> 538.imagick_r 3.18% -0.80%
>>> 544.nab_r 5.76% -1.11%
>>> Avg 2.52% 0.36%
>>> From the above data, the implementation D is always better than A,
>it’s a
>>> surprising to me, not sure what’s the reason for this.
>>
>> D probably inhibits most interesting loop transforms (check SPEC FP
>> performance).
>
>The call to .DEFERRED_INIT is marked as ECF_CONST:
>
>/* A function to represent an artifical initialization to an
>uninitialized
> automatic variable. The first argument is the variable itself, the
> second argument is the initialization type. */
>DEF_INTERNAL_FN (DEFERRED_INIT, ECF_CONST | ECF_LEAF | ECF_NOTHROW,
>NULL)
>
>So, I assume that such const call should minimize the impact to loop
>optimizations. But yes, it will still inhibit some of the loop
>transformations.
>
>> It will also most definitely disallow SRA which, when
>> an aggregate is not completely elided, tends to grow code.
>
>Make sense to me.
>
>The run-time performance data for D and A are actually very similar as
>I posted in the previous email (I listed it here for convenience)
>
>Run-time performance overhead with A and D:
>
>benchmarks A / no D /no
>
>500.perlbench_r 1.25% 1.25%
>502.gcc_r 0.68% 1.80%
>505.mcf_r 0.68% 0.14%
>520.omnetpp_r 4.83% 4.68%
>523.xalancbmk_r 0.18% 1.96%
>525.x264_r 1.55% 2.07%
>531.deepsjeng_ 11.57% 11.85%
>541.leela_r 0.64% 0.80%
>557.xz_ -0.41% -0.41%
>
>507.cactuBSSN_r 0.44% 0.44%
>508.namd_r 0.34% 0.34%
>510.parest_r 0.17% 0.25%
>511.povray_r 56.57% 57.27%
>519.lbm_r 0.00% 0.00%
>521.wrf_r -0.28% -0.37%
>526.blender_r 16.96% 17.71%
>527.cam4_r 0.70% 0.53%
>538.imagick_r 2.40% 2.40%
>544.nab_r 0.00% -0.65%
>
>avg 5.17% 5.37%
>
>Especially for the SPEC FP benchmarks, I didn’t see too much
>performance difference between A and D.
>I guess that the RTL optimizations might be enough to get rid of most
>of the overhead introduced by the additional initialization.
>
>>
>>> ********stack usage data, I added -fstack-usage to the compilation
>line when
>>> compiling CPU2017 benchmarks. And all the *.su files were generated
>for each
>>> of the modules.
>>> Since there a lot of such files, and the stack size information are
>embedded
>>> in each of the files. I just picked up one benchmark 511.povray to
>>> check. Which is the one that
>>> has the most runtime overhead when adding initialization (both A and
>D).
>>> I identified all the *.su files that are different between A and D
>and do a
>>> diff on those *.su files, and looks like that the stack size is much
>higher
>>> with D than that with A, for example:
>>> $ diff build_base_auto_init.D.0000/bbox.su
>>> build_base_auto_init.A.0000/bbox.su5c5
>>> < bbox.cpp:1782:12:int pov::sort_and_split(pov::BBOX_TREE**,
>>> pov::BBOX_TREE**&, long int*, long int, long int) 160 static
>>> ---
>>> > bbox.cpp:1782:12:int pov::sort_and_split(pov::BBOX_TREE**,
>>> pov::BBOX_TREE**&, long int*, long int, long int) 96 static
>>> $ diff build_base_auto_init.D.0000/image.su
>>> build_base_auto_init.A.0000/image.su
>>> 9c9
>>> < image.cpp:240:6:void pov::bump_map(double*, pov::TNORMAL*,
>double*) 624
>>> static
>>> ---
>>> > image.cpp:240:6:void pov::bump_map(double*, pov::TNORMAL*,
>double*) 272
>>> static
>>> ….
>>> Looks like that implementation D has more stack size impact than A.
>>> Do you have any insight on what the reason for this?
>>
>> D will keep all initialized aggregates as aggregates and live which
>> means stack will be allocated for it. With A the usual optimizations
>> to reduce stack usage can be applied.
>
>I checked the routine “poverties::bump_map” in 511.povray_r since it
>has a lot stack increase
>due to implementation D, by examine the IR immediate before RTL
>expansion phase.
>(image.cpp.244t.optimized), I found that we have the following
>additional statements for the array elements:
>
>void pov::bump_map (double * EPoint, struct TNORMAL * Tnormal, double
>* normal)
>{
>…
> double p3[3];
> double p2[3];
> double p1[3];
> float colour3[5];
> float colour2[5];
> float colour1[5];
>…
> # DEBUG BEGIN_STMT
> colour1 = .DEFERRED_INIT (colour1, 2);
> colour2 = .DEFERRED_INIT (colour2, 2);
> colour3 = .DEFERRED_INIT (colour3, 2);
> # DEBUG BEGIN_STMT
> MEM <double> [(double[3] *)&p1] = p1$0_144(D);
> MEM <double> [(double[3] *)&p1 + 8B] = p1$1_135(D);
> MEM <double> [(double[3] *)&p1 + 16B] = p1$2_138(D);
> p1 = .DEFERRED_INIT (p1, 2);
> # DEBUG D#12 => MEM <double> [(double[3] *)&p1]
> # DEBUG p1$0 => D#12
> # DEBUG D#11 => MEM <double> [(double[3] *)&p1 + 8B]
> # DEBUG p1$1 => D#11
> # DEBUG D#10 => MEM <double> [(double[3] *)&p1 + 16B]
> # DEBUG p1$2 => D#10
> MEM <double> [(double[3] *)&p2] = p2$0_109(D);
> MEM <double> [(double[3] *)&p2 + 8B] = p2$1_111(D);
> MEM <double> [(double[3] *)&p2 + 16B] = p2$2_254(D);
> p2 = .DEFERRED_INIT (p2, 2);
> # DEBUG D#9 => MEM <double> [(double[3] *)&p2]
> # DEBUG p2$0 => D#9
> # DEBUG D#8 => MEM <double> [(double[3] *)&p2 + 8B]
> # DEBUG p2$1 => D#8
> # DEBUG D#7 => MEM <double> [(double[3] *)&p2 + 16B]
> # DEBUG p2$2 => D#7
> MEM <double> [(double[3] *)&p3] = p3$0_256(D);
> MEM <double> [(double[3] *)&p3 + 8B] = p3$1_258(D);
> MEM <double> [(double[3] *)&p3 + 16B] = p3$2_260(D);
> p3 = .DEFERRED_INIT (p3, 2);
> ….
>}
>
>I guess that the above “MEM <double>….. = …” are the ones that make the
>differences. Which phase introduced them?
Looks like SRA. But you can just dump all and grep for the first occurrence.
>>
>>> Let me know if you have any comments and suggestions.
>>
>> First of all I would check whether the prototype implementations
>> work as expected.
>I have done such check with small testing cases already, checking the
>IR generated with the implementation A or D, mainly
>Focus on *.c.006t.gimple. and *.c.*t.expand, all worked as expected.
>
>For the CPU2017, for example as the above, I also checked the IR for
>both A and D, looks like all worked as expected.
>
>Thanks.
>
>Qing
>>
>> Richard.
>>
>>
>>> thanks.
>>> Qing
>>> On Jan 13, 2021, at 1:39 AM, Richard Biener <rguent...@suse.de>
>>> wrote:
>>>
>>> On Tue, 12 Jan 2021, Qing Zhao wrote:
>>>
>>> Hi,
>>>
>>> Just check in to see whether you have any comments
>>> and suggestions on this:
>>>
>>> FYI, I have been continue with Approach D
>>> implementation since last week:
>>>
>>> D. Adding calls to .DEFFERED_INIT during
>>> gimplification, expand the .DEFFERED_INIT during
>>> expand to
>>> real initialization. Adjusting uninitialized pass
>>> with the new refs with “.DEFFERED_INIT”.
>>>
>>> For the remaining work of Approach D:
>>>
>>> ** complete the implementation of
>>> -ftrivial-auto-var-init=pattern;
>>> ** complete the implementation of uninitialized
>>> warnings maintenance work for D.
>>>
>>> I have completed the uninitialized warnings
>>> maintenance work for D.
>>> And finished partial of the
>>> -ftrivial-auto-var-init=pattern implementation.
>>>
>>> The following are remaining work of Approach D:
>>>
>>> ** -ftrivial-auto-var-init=pattern for VLA;
>>> **add a new attribute for variable:
>>> __attribute((uninitialized)
>>> the marked variable is uninitialized intentionaly
>>> for performance purpose.
>>> ** adding complete testing cases;
>>>
>>> Please let me know if you have any objection on my
>>> current decision on implementing approach D.
>>>
>>> Did you do any analysis on how stack usage and code size are
>>> changed
>>> with approach D? How does compile-time behave (we could gobble
>>> up
>>> lots of .DEFERRED_INIT calls I guess)?
>>>
>>> Richard.
>>>
>>> Thanks a lot for your help.
>>>
>>> Qing
>>>
>>> On Jan 5, 2021, at 1:05 PM, Qing Zhao
>>> via Gcc-patches
>>> <gcc-patches@gcc.gnu.org> wrote:
>>>
>>> Hi,
>>>
>>> This is an update for our previous
>>> discussion.
>>>
>>> 1. I implemented the following two
>>> different implementations in the latest
>>> upstream gcc:
>>>
>>> A. Adding real initialization during
>>> gimplification, not maintain the
>>> uninitialized warnings.
>>>
>>> D. Adding calls to .DEFFERED_INIT
>>> during gimplification, expand the
>>> .DEFFERED_INIT during expand to
>>> real initialization. Adjusting
>>> uninitialized pass with the new refs
>>> with “.DEFFERED_INIT”.
>>>
>>> Note, in this initial implementation,
>>> ** I ONLY implement
>>> -ftrivial-auto-var-init=zero, the
>>> implementation of
>>> -ftrivial-auto-var-init=pattern
>>> is not done yet. Therefore, the
>>> performance data is only about
>>> -ftrivial-auto-var-init=zero.
>>>
>>> ** I added an temporary option
>>> -fauto-var-init-approach=A|B|C|D to
>>> choose implementation A or D for
>>> runtime performance study.
>>> ** I didn’t finish the uninitialized
>>> warnings maintenance work for D. (That
>>> might take more time than I expected).
>>>
>>> 2. I collected runtime data for CPU2017
>>> on a x86 machine with this new gcc for
>>> the following 3 cases:
>>>
>>> no: default. (-g -O2 -march=native )
>>> A: default +
>>> -ftrivial-auto-var-init=zero
>>> -fauto-var-init-approach=A
>>> D: default +
>>> -ftrivial-auto-var-init=zero
>>> -fauto-var-init-approach=D
>>>
>>> And then compute the slowdown data for
>>> both A and D as following:
>>>
>>> benchmarks A / no D /no
>>>
>>> 500.perlbench_r 1.25% 1.25%
>>> 502.gcc_r 0.68% 1.80%
>>> 505.mcf_r 0.68% 0.14%
>>> 520.omnetpp_r 4.83% 4.68%
>>> 523.xalancbmk_r 0.18% 1.96%
>>> 525.x264_r 1.55% 2.07%
>>> 531.deepsjeng_ 11.57% 11.85%
>>> 541.leela_r 0.64% 0.80%
>>> 557.xz_ -0.41% -0.41%
>>>
>>> 507.cactuBSSN_r 0.44% 0.44%
>>> 508.namd_r 0.34% 0.34%
>>> 510.parest_r 0.17% 0.25%
>>> 511.povray_r 56.57% 57.27%
>>> 519.lbm_r 0.00% 0.00%
>>> 521.wrf_r -0.28% -0.37%
>>> 526.blender_r 16.96% 17.71%
>>> 527.cam4_r 0.70% 0.53%
>>> 538.imagick_r 2.40% 2.40%
>>> 544.nab_r 0.00% -0.65%
>>>
>>> avg 5.17% 5.37%
>>>
>>> From the above data, we can see that in
>>> general, the runtime performance
>>> slowdown for
>>> implementation A and D are similar for
>>> individual benchmarks.
>>>
>>> There are several benchmarks that have
>>> significant slowdown with the new added
>>> initialization for both
>>> A and D, for example, 511.povray_r,
>>> 526.blender_, and 531.deepsjeng_r, I
>>> will try to study a little bit
>>> more on what kind of new initializations
>>> introduced such slowdown.
>>>
>>> From the current study so far, I think
>>> that approach D should be good enough
>>> for our final implementation.
>>> So, I will try to finish approach D with
>>> the following remaining work
>>>
>>> ** complete the implementation of
>>> -ftrivial-auto-var-init=pattern;
>>> ** complete the implementation of
>>> uninitialized warnings maintenance work
>>> for D.
>>>
>>> Let me know if you have any comments and
>>> suggestions on my current and future
>>> work.
>>>
>>> Thanks a lot for your help.
>>>
>>> Qing
>>>
>>> On Dec 9, 2020, at 10:18 AM,
>>> Qing Zhao via Gcc-patches
>>> <gcc-patches@gcc.gnu.org>
>>> wrote:
>>>
>>> The following are the
>>> approaches I will implement
>>> and compare:
>>>
>>> Our final goal is to keep
>>> the uninitialized warning
>>> and minimize the run-time
>>> performance cost.
>>>
>>> A. Adding real
>>> initialization during
>>> gimplification, not maintain
>>> the uninitialized warnings.
>>> B. Adding real
>>> initialization during
>>> gimplification, marking them
>>> with “artificial_init”.
>>> Adjusting uninitialized
>>> pass, maintaining the
>>> annotation, making sure the
>>> real init not
>>> Deleted from the fake
>>> init.
>>> C. Marking the DECL for an
>>> uninitialized auto variable
>>> as “no_explicit_init” during
>>> gimplification,
>>> maintain this
>>> “no_explicit_init” bit till
>>> after
>>> pass_late_warn_uninitialized,
>>> or till pass_expand,
>>> add real initialization
>>> for all DECLs that are
>>> marked with
>>> “no_explicit_init”.
>>> D. Adding .DEFFERED_INIT
>>> during gimplification,
>>> expand the .DEFFERED_INIT
>>> during expand to
>>> real initialization.
>>> Adjusting uninitialized pass
>>> with the new refs with
>>> “.DEFFERED_INIT”.
>>>
>>> In the above, approach A
>>> will be the one that have
>>> the minimum run-time cost,
>>> will be the base for the
>>> performance
>>> comparison.
>>>
>>> I will implement approach D
>>> then, this one is expected
>>> to have the most run-time
>>> overhead among the above
>>> list, but
>>> Implementation should be the
>>> cleanest among B, C, D.
>>> Let’s see how much more
>>> performance overhead this
>>> approach
>>> will be. If the data is
>>> good, maybe we can avoid the
>>> effort to implement B, and
>>> C.
>>>
>>> If the performance of D is
>>> not good, I will implement B
>>> or C at that time.
>>>
>>> Let me know if you have any
>>> comment or suggestions.
>>>
>>> Thanks.
>>>
>>> Qing
>>>
>>> --
>>> Richard Biener <rguent...@suse.de>
>>> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409
>>> Nuernberg,
>>> Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
