From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by sourceware.org (Postfix) with ESMTPS id 410EC386101A for ; Wed, 30 Jun 2021 17:20:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 410EC386101A Received: by mail-yb1-xb35.google.com with SMTP id r135so6312357ybc.0 for ; Wed, 30 Jun 2021 10:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=betmSLqHrN180HyD3FbDUlKurVWrQz9AQGBKLKoHZ7s=; b=JrlGSIGEKFKelQV7hujD8Zqq0KNWFG7SOjuOZE6N4H3D5Vw8zYk619w/IB8GXO965A 2D7aPm/BUC/5xiF81ILqejZj2GUSwLviwYc//6wBlXy6SrTlKr1J6+ljxS4O1qDqfp7r 6nZ2tZfeWW5C36ZQUXoLVcDm9Ov4NH8yVt+dx6B/QQQfSrgC5QB/cfBslMsFXpEHxqER WQzr2jwegu9XiFjBsC5OUG0pyON/9omLMn+K5kt1/OlyW0PBVOMGtjCJk5vqPfhsI288 SVXTzYkRbiP+lVzni3qvNYfwsd6UU86Jt4cTfYkswUBXi2XRqBlYPtPROd18/vV/MiYg 7XOw== X-Gm-Message-State: AOAM5316FN7vZUrNF0HVci6TEcRX0Fued9ig3qaOGmcYz83k4F1KUvpa qwt9tGXmK9ujSE1DECq47vtUWh1ikVeeKfrMmjE= X-Google-Smtp-Source: ABdhPJxXvybz7oeSJAEpf5tm3271/HvmTv0UUmGgqskEDzw0XOUWH6M/MdpRjNSR08b1uuLuJVOkk6AphgeGT1eiw0U= X-Received: by 2002:a25:8b12:: with SMTP id i18mr44177502ybl.162.1625073631863; Wed, 30 Jun 2021 10:20:31 -0700 (PDT) MIME-Version: 1.0 References: <004A0552-4D2E-48F4-8474-5902E462D77B@oracle.com> In-Reply-To: <004A0552-4D2E-48F4-8474-5902E462D77B@oracle.com> From: Andrew Pinski Date: Wed, 30 Jun 2021 10:20:18 -0700 Message-ID: Subject: Re: HELP!! How to inhibit optimizations applied to .DEFERRED_INIT argument? To: Qing Zhao Cc: Richard Biener , richard Sandiford , gcc-patches Qing Zhao via , kees cook Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, PLING_QUERY, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 17:20:34 -0000 On Wed, Jun 30, 2021 at 8:47 AM Qing Zhao via Gcc-patches wrote: > > I came up with a very simple testing case that can repeat the same issue: > > [qinzhao@localhost gcc]$ cat t.c > extern void bar (int); > void foo (int a) > { > int i; > for (i =3D 0; i < a; i++) { > if (__extension__({int size2; > size2 =3D 4; > size2 > 5;})) > bar (a); > } > } You should show the full dump, What we have is the following: size2_3 =3D PHI : size2_12 =3D .DEFERRED_INIT (size2_3, 2); size2_13 =3D 4; So CCP decides to propagate 4 into the PHI and then decides size2_1(D) is undefined so size2_3 is then considered 4 and propagates it into the .DEFERRED_INIT. Thanks, Andrew > > [qinzhao@localhost gcc]$ /home/qinzhao/Work/GCC/gcc_build_debug/gcc/xgcc = -B/home/qinzhao/Work/GCC/gcc_build_debug/gcc/ -std=3Dc99 -m64 -march=3Dn= ative -ftrivial-auto-var-init=3Dzero t.c -fdump-tree-all -O1 > t.c: In function =E2=80=98foo=E2=80=99: > t.c:11:1: error: =E2=80=98DEFFERED_INIT=E2=80=99 calls should have the sa= me LHS as the first argument > 11 | } > | ^ > size2_12 =3D .DEFERRED_INIT (4, 2); > during GIMPLE pass: ccp > dump file: a-t.c.032t.ccp1 > t.c:11:1: internal compiler error: verify_gimple failed > 0x143ee47 verify_gimple_in_cfg(function*, bool) > ../../latest_gcc/gcc/tree-cfg.c:5501 > 0x122d799 execute_function_todo > ../../latest_gcc/gcc/passes.c:2042 > 0x122c74b do_per_function > ../../latest_gcc/gcc/passes.c:1687 > 0x122d986 execute_todo > ../../latest_gcc/gcc/passes.c:2096 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. > See for instructions. > > In this testing case, both =E2=80=9CI=E2=80=9D and =E2=80=9Csize2=E2=80= =9D are auto vars that are not initialized at declaration but are initializ= ed later by assignment. > However, =E2=80=9CI=E2=80=9D doesn=E2=80=99t have any issue, but =E2=80= =9Csize2=E2=80=9D has such issue. > > ******=E2=80=9Cssa=E2=80=9D dump: > > : > i_7 =3D .DEFERRED_INIT (i_6(D), 2); > i_8 =3D 0; > goto ; [INV] > > : > size2_12 =3D .DEFERRED_INIT (size2_3, 2); > size2_13 =3D 4; > > ******=E2=80=9Dccp1=E2=80=9D dump: > > : > i_7 =3D .DEFERRED_INIT (i_6(D), 2); > goto ; [INV] > > : > size2_12 =3D .DEFERRED_INIT (4, 2); > > So, I am wondering: Is it possible that =E2=80=9Cssa=E2=80=9D phase have= a bug ? > > Qing > > > On Jun 30, 2021, at 9:39 AM, Richard Biener wrote: > > > > On Wed, 30 Jun 2021, Qing Zhao wrote: > > > >> > >> > >> On Jun 30, 2021, at 2:46 AM, Richard Biener > wrote: > >> > >> On Wed, 30 Jun 2021, Qing Zhao wrote: > >> > >> Hi, > >> > >> I am testing the 4th patch of -ftrivial-auto-var-init with CPU2017 tod= ay, and found the following issues: > >> > >> ****In the dump file of =E2=80=9C*t.i.031t.objsz1=E2=80=9D, we have: > >> > >> : > >> __s1_len_217 =3D .DEFERRED_INIT (__s1_len_176, 2); > >> __s2_len_218 =3D .DEFERRED_INIT (__s2_len_177, 2); > >> > >> I looks like this .DEFERRED_INIT initializes an already initialized > >> variable. > >> > >> Yes. > >> > >> For cases like the following: > >> > >> int s2_len; > >> s2_len =3D 4; > >> > >> i.e, the initialization is not at the declaration. > >> > >> We cannot avoid initialization for such cases. > > > > But I'd have expected > > > > s2_len =3D .DEFERRED_INIT (s2_len, 0); > > s2_len =3D 4; > > > > from the above - thus the deferred init _before_ the first > > "use" which is the explicit init. How does the other order > > happen to materialize? As said, I believe it shouldn't. > > > >> I'd expect to only ever see default definition SSA names > >> as first argument to .DEFERRED_INIT. > >> > >> You mean something like: > >> __s2_len_218 =3D .DEFERRED_INIT (__s2_len, 2); > > > > No, > > > > __s2_len_218 =3D .DEFERRED_INIT (__s2_len_217(D), 2); > > > >> ? > >> > >> > >> __s2_len_219 =3D 7; > >> if (__s2_len_219 <=3D 3) > >> goto ; [INV] > >> else > >> goto ; [INV] > >> > >> : > >> _1 =3D (long unsigned int) i_175; > >> > >> > >> ****However, after =E2=80=9Cccp=E2=80=9D, in =E2=80=9Ct.i.032t.ccp1=E2= =80=9D, we have: > >> > >> : > >> __s1_len_217 =3D .DEFERRED_INIT (__s1_len_176, 2); > >> __s2_len_218 =3D .DEFERRED_INIT (7, 2); > >> _36 =3D (long unsigned int) i_175; > >> _37 =3D _36 * 8; > >> _38 =3D argv_220(D) + _37; > >> > >> > >> Looks like that the optimization =E2=80=9Cccp=E2=80=9D replaced the fi= rst argument of the call .DEFERRED_INIT with the constant 7. > >> This should be avoided. > >> > >> (NOTE, this issue existed in the previous patches, however, only expos= ed with this version since I added more verification > >> code in tree-cfg.c to verify the call to .DEFERRED_INIT). > >> > >> I am wondering what=E2=80=99s the best solution to this problem? > >> > >> I think you have to trace where this "bogus" .DEFERRED_INIT comes from > >> originally. Or alternatively, if this is unavoidable, > >> > >> This is unavoidable, I believe. > > > > I see but don't believe it yet ;) > > > >> add "constant > >> folding" of .DEFERRED_INIT so that defered init of an initialized > >> object becomes the object itself, thus retain the previous - eventuall= y > >> partial - initialization only. > >> > >> If this additional .DEFERRED_INIT will be kept till RTL expansion phas= e, then it will become a real initialization: > >> > >> i.e. > >> > >> s2_len =3D 0; //.DEFERRED_INIT expanded > >> s2_len =3D 4; // the original initialization > >> > >> Then the first initialization will be eliminated by current RTL optimi= zation easily, right? > > > > Well, in your example above it's effectively elimiated by GIMPLE > > optimization. IIRC you're using the first argument of .DEFERRED_INIT > > for diagnostic purposes only, correct? > > > > Richard. > > > >> Qing > >> > >> > >> Richard. > >> > >> Can we add any attribute to the internal function argument to prevent = later optimizations that might applied on it? > >> Or just update =E2=80=9Cccp=E2=80=9D phase to specially handle calls t= o .DEFERRED_INIT? (Not sure whether there are other phases have the > >> Same issue?) > >> > >> Let me know if you have any suggestion. > >> > >> Thanks a lot for your help. > >> > >> Qing > >> > >> -- > >> Richard Biener > > >> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernber= g, > >> Germany; GF: Felix Imend=C3=B6rffer; HRB 36809 (AG Nuernberg) > >> > >> > > > > -- > > Richard Biener > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg= , > > Germany; GF: Felix Imend=C3=B6rffer; HRB 36809 (AG Nuernberg) >