Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-02-02 Thread Qing Zhao via Gcc-patches
Hi, With the following patch: [qinzhao@localhost gcc]$ git diff tree-ssa-structalias.c diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c index cf653be..bd18841 100644 --- a/gcc/tree-ssa-structalias.c +++ b/gcc/tree-ssa-structalias.c @@ -4851,6 +4851,30 @@

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-02-02 Thread Qing Zhao via Gcc-patches
> On Feb 2, 2021, at 1:43 AM, Richard Biener wrote: > > On Mon, 1 Feb 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> I have adjusted SRA phase to split calls to DEFERRED_INIT per you suggestion. >> >> And now the routine “bump_map” in 511.povray is like following: >> ... >> >> # DEBUG

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-02-01 Thread Richard Biener
On Mon, 1 Feb 2021, Qing Zhao wrote: > Hi, Richard, > > I have adjusted SRA phase to split calls to DEFERRED_INIT per you suggestion. > > And now the routine “bump_map” in 511.povray is like following: > ... > > # DEBUG BEGIN_STMT > xcoor = 0.0; > ycoor = 0.0; > # DEBUG BEGIN_STMT >

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-02-01 Thread Qing Zhao via Gcc-patches
Hi, Richard, I have adjusted SRA phase to split calls to DEFERRED_INIT per you suggestion. And now the routine “bump_map” in 511.povray is like following: ... # DEBUG BEGIN_STMT xcoor = 0.0; ycoor = 0.0; # DEBUG BEGIN_STMT index = .DEFERRED_INIT (index, 2); index2 = .DEFERRED_INIT

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-18 Thread Qing Zhao via Gcc-patches
> On Jan 18, 2021, at 7:09 AM, Richard Sandiford > wrote: > > Qing Zhao writes: > 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

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-18 Thread Richard Sandiford via Gcc-patches
Qing Zhao writes: 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

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-15 Thread Qing Zhao via Gcc-patches
> On Jan 15, 2021, at 11:22 AM, Richard Biener wrote: > > On January 15, 2021 5:16:40 PM GMT+01:00, Qing Zhao > wrote: >> >> >>> On Jan 15, 2021, at 2:11 AM, Richard Biener >> wrote: >>> >>> >>> >>> On Thu, 14 Jan 2021, Qing Zhao wrote: >>> Hi,

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-15 Thread Richard Biener
On January 15, 2021 5:16:40 PM GMT+01:00, Qing Zhao wrote: > > >> On Jan 15, 2021, at 2:11 AM, Richard Biener >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

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-15 Thread Qing Zhao via Gcc-patches
> On Jan 15, 2021, at 2:11 AM, Richard Biener 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

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-15 Thread Richard Biener
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%

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-14 Thread Qing Zhao via Gcc-patches
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

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-13 Thread Richard Biener
On Wed, 13 Jan 2021, Qing Zhao wrote: > > > > On Jan 13, 2021, at 9:10 AM, Richard Biener wrote: > > > > On Wed, 13 Jan 2021, Qing Zhao wrote: > > > >> > >> > >>> On Jan 13, 2021, at 1:39 AM, Richard Biener wrote: > >>> > >>> On Tue, 12 Jan 2021, Qing Zhao wrote: > >>> > Hi, >

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-13 Thread Qing Zhao via Gcc-patches
> On Jan 13, 2021, at 9:10 AM, Richard Biener wrote: > > On Wed, 13 Jan 2021, Qing Zhao wrote: > >> >> >>> On Jan 13, 2021, at 1:39 AM, Richard Biener wrote: >>> >>> On Tue, 12 Jan 2021, Qing Zhao wrote: >>> Hi, Just check in to see whether you have any comments and

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-13 Thread Richard Biener
On Wed, 13 Jan 2021, Qing Zhao wrote: > > > > On Jan 13, 2021, at 1:39 AM, Richard Biener 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

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-13 Thread Qing Zhao via Gcc-patches
> On Jan 13, 2021, at 1:39 AM, Richard Biener 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

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-12 Thread Richard Biener
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

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-12 Thread Qing Zhao via Gcc-patches
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

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-05 Thread Qing Zhao via Gcc-patches
I am attaching my current (incomplete) patch to gcc for your reference. From a71eb73bee5857440c4ff67c4c82be115e0675cb Mon Sep 17 00:00:00 2001 From: qing zhao Date: Sat, 12 Dec 2020 00:02:28 +0100 Subject: [PATCH] First version of -ftrivial-auto-var-init --- gcc/common.opt| 35

The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2021-01-05 Thread Qing Zhao via Gcc-patches
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,