From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 1A8863857806 for ; Wed, 2 Dec 2020 08:45:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1A8863857806 Received: by mail-ej1-x62a.google.com with SMTP id f23so2447234ejt.8 for ; Wed, 02 Dec 2020 00:45:47 -0800 (PST) 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=AEzJu3uOTBTY8XgOmEeG0YFWHDrMH6ENbBnFf39xmI8=; b=REVxaFZklGQPAPNAYLXH6eTQCyzrFBRKvS7B2rO9ob92KuGRbKzg40xETKLC1nYcGS ZwLJl1wOT3xevM/68aBFpByFtJvO55YjUQwkZ2Tz6Y0JJ7UNkdzRpuHv97NIo5DCLxBN rjU44VTYsGGlpDy7ZFhIjFxxXq0YeihWzlAps40UDxJp9Bssra3cGV9gZJdt8o4+0I7t kmrPjh6rnGDieTtpuI3t/nsp5wIxYtXI4cFOsIcQ58hiFIOmchfISkYK0srC8ZfA6QO+ FmJfH3ZD2HEU87ZUsnE0QTXlKMdvd4CK47BFAeUN8ZC3Ee4rcFjWrnfSL6n36g+yXSmV umUA== X-Gm-Message-State: AOAM533PtbSByO4aD7fsaQ/32zAMuCD4mWw3LHtJ5rvBe0qg1F8UUI0H 4VE+ElechbIZaZXPeRiqSlnd6rsWdlh+uZyWlbs= X-Google-Smtp-Source: ABdhPJz2fw4WMf4kXoLKUdkHLNE6QwPZA2q4lXGEV8YHAZXTWq0TLLnyJvIdX/xNo/gy3+yB1t/Kp/OEW1BDO0uMX+Y= X-Received: by 2002:a17:906:6b88:: with SMTP id l8mr1312680ejr.482.1606898746093; Wed, 02 Dec 2020 00:45:46 -0800 (PST) MIME-Version: 1.0 References: <217BE64F-A623-4453-B45B-D38B66B71B72@ORACLE.COM> <15EA64C7-D75F-4CE1-92C8-6940186A512A@ORACLE.COM> <7618DD31-87EC-4003-B1DD-E318E5369A71@ORACLE.COM> In-Reply-To: <7618DD31-87EC-4003-B1DD-E318E5369A71@ORACLE.COM> From: Richard Biener Date: Wed, 2 Dec 2020 09:45:35 +0100 Message-ID: Subject: Re: How to traverse all the local variables that declared in the current routine? To: Qing Zhao Cc: Richard Sandiford , gcc Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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, 02 Dec 2020 08:45:49 -0000 On Tue, Dec 1, 2020 at 8:49 PM Qing Zhao wrote: > > Hi, Richard, > > Could you please comment on the following approach: > > Instead of adding the zero-initializer quite late at the pass =E2=80=9Cpa= ss_expand=E2=80=9D, we can add it as early as during gimplification. > However, we will mark these new added zero-initializers as =E2=80=9Cartif= icial=E2=80=9D. And passing this =E2=80=9Cartificial=E2=80=9D information t= o > =E2=80=9Cpass_early_warn_uninitialized=E2=80=9D and =E2=80=9Cpass_late_wa= rn_uninitialized=E2=80=9D, in these two uninitialized variable analysis pas= ses, > (i.e., in tree-sea-uninit.c) We will update the checking on =E2=80=9Cssa_= undefined_value_p=E2=80=9D to consider =E2=80=9Cartificial=E2=80=9D zero-i= nitializers. > (i.e, if the def_stmt is marked with =E2=80=9Cartificial=E2=80=9D, then i= t=E2=80=99s a undefined value). > > With such approach, we should be able to address all those conflicts. > > Do you see any obvious issue with this approach? Yes, DSE will happily elide an explicit zero-init following the artificial one leading to false uninit diagnostics. What's the intended purpose of the zero-init? Richard. > Thanks a lot for your help. > > Qing > > > On Nov 25, 2020, at 3:11 AM, Richard Biener = wrote: > > > > I am planing to add a new phase immediately after =E2=80=9Cpass_late_warn= _uninitialized=E2=80=9D to initialize all auto-variables that are > not explicitly initialized in the declaration, the basic idea is followin= g: > > ** The proposal: > > A. add a new GCC option: (same name and meaning as CLANG) > -ftrivial-auto-var-init=3D[pattern|zero], similar pattern init as CLANG; > > B. add a new attribute for variable: > __attribute((uninitialized) > the marked variable is uninitialized intentionaly for performance purpose= . > > C. The implementation needs to keep the current static warning on uniniti= alized > variables untouched in order to avoid "forking the language". > > > ** The implementation: > > There are two major requirements for the implementation: > > 1. all auto-variables that do not have an explicit initializer should be = initialized to > zero by this option. (Same behavior as CLANG) > > 2. keep the current static warning on uninitialized variables untouched. > > In order to satisfy 1, we should check whether an auto-variable has initi= alizer > or not; > In order to satisfy 2, we should add this new transformation after > "pass_late_warn_uninitialized". > > So, we should be able to check whether an auto-variable has initializer o= r not after =E2=80=9Cpass_late_warn_uninitialized=E2=80=9D, > If Not, then insert an initialization for it. > > For this purpose, I guess that =E2=80=9CFOR_EACH_LOCAL_DECL=E2=80=9D migh= t be better? > > > I think both as long as they are source-level auto-variables. Then which = one is better? > > > Another issue is, in order to check whether an auto-variable has initiali= zer, I plan to add a new bit in =E2=80=9Cdecl_common=E2=80=9D as: > /* In a VAR_DECL, this is DECL_IS_INITIALIZED. */ > unsigned decl_is_initialized :1; > > /* IN VAR_DECL, set when the decl is initialized at the declaration. */ > #define DECL_IS_INITIALIZED(NODE) \ > (DECL_COMMON_CHECK (NODE)->decl_common.decl_is_initialized) > > set this bit when setting DECL_INITIAL for the variables in FE. then keep= it > even though DECL_INITIAL might be NULLed. > > > For locals it would be more reliable to set this flag-Wmaybe-uninitialize= d. > > > > You mean I can set the flag =E2=80=9CDECL_IS_INITIALIZED (decl)=E2=80=9D = inside the routine =E2=80=9Cgimpley_decl_expr=E2=80=9D (gimplify.c) as fol= lowing: > > if (VAR_P (decl) && !DECL_EXTERNAL (decl)) > { > tree init =3D DECL_INITIAL (decl); > ... > if (init && init !=3D error_mark_node) > { > if (!TREE_STATIC (decl)) > { > DECL_IS_INITIALIZED(decl) =3D 1; > } > > Is this enough for all Frontends? Are there other places that I need to m= aintain this bit? > > > > Do you have any comment and suggestions? > > > As said above - do you want to cover registers as well as locals? > > > All the locals from the source-code point of view should be covered. (F= rom my study so far, looks like that Clang adds that phase in FE). > If GCC adds this phase in FE, then the following design requirement > > C. The implementation needs to keep the current static warning on uniniti= alized > variables untouched in order to avoid "forking the language=E2=80=9D. > > cannot be satisfied. Since gcc=E2=80=99s uninitialized variables analysi= s is applied quite late. > > So, we have to add this new phase after =E2=80=9Cpass_late_warn_uninitial= ized=E2=80=9D. > > I'd do > the actual zeroing during RTL expansion instead since otherwise you > have to figure youself whether a local is actually used (see expand_stack= _vars) > > > Adding this new transformation during RTL expansion is okay. I will che= ck on this in more details to see how to add it to RTL expansion phase. > > > Note that optimization will already made have use of "uninitialized" stat= e > of locals so depending on what the actual goal is here "late" may be too = late. > > > This is a really good point=E2=80=A6 > > In order to avoid optimization to use the =E2=80=9Cuninitialized=E2=80= =9D state of locals, we should add the zeroing phase as early as possible (= adding it in FE might be best > for this issue). However, if we have to met the following requirement: > > > So is optimization supposed to pick up zero or is it supposed to act > as if the initializer > is unknown? > > C. The implementation needs to keep the current static warning on uniniti= alized > variables untouched in order to avoid "forking the language=E2=80=9D. > > We have to move the new phase after all the uninitialized analysis is don= e in order to avoid =E2=80=9Cforking the language=E2=80=9D. > > So, this is a problem that is not easy to resolve. > > > Indeed, those are conflicting goals. > > Do you have suggestion on this? > > > No, not any easy ones. Doing more of the uninit analysis early (there > is already an early > uninit pass) which would mean doing IPA analysis turing GCC into more > of a static analysis > tool. Theres the analyzer now, not sure if that can employ an early > LTO phase for example. > > > > > Richard. > >