From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 58ABB3855027 for ; Wed, 30 Jun 2021 14:39:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 58ABB3855027 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 5DE3021A32; Wed, 30 Jun 2021 14:39:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1625063964; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3/7AF56FtpH/4iv9+81vy9Ce1Tr4k3RUwrG/cPXeu+0=; b=06sFlwJh/5/I9yoy37VAOsgIuZXfV/iIFSwTljCF7H7l7sYYankGFge21s0DOJlw4w8/mN 6Ux5GEKYI17v3s2XjbmGS8jeGZgpnflGofRTQQU5eApSjmzHnquWoBQc4qTdDDD32lhGiF 5POye7eDsrL2HHZcidVcJYPVVgbhFuk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1625063964; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3/7AF56FtpH/4iv9+81vy9Ce1Tr4k3RUwrG/cPXeu+0=; b=sbPYr1o+PYOWXPCoLv/82iNOZm7ndE2qGvc0NGwWJY0mg/E9cWGmNFAvZUCjs/SYKjCXWa UMIbigNJhGyuaSAQ== Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 51183A3B8A; Wed, 30 Jun 2021 14:39:24 +0000 (UTC) Date: Wed, 30 Jun 2021 16:39:24 +0200 (CEST) From: Richard Biener To: Qing Zhao cc: richard Sandiford , kees cook , gcc-patches Qing Zhao via Subject: Re: HELP!! How to inhibit optimizations applied to .DEFERRED_INIT argument? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, PLING_QUERY, 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 14:39:27 -0000 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 today, and found the following issues: > > ****In the dump file of “*t.i.031t.objsz1”, we have: > > : > __s1_len_217 = .DEFERRED_INIT (__s1_len_176, 2); > __s2_len_218 = .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 = 4; > > i.e, the initialization is not at the declaration. > > We cannot avoid initialization for such cases. But I'd have expected s2_len = .DEFERRED_INIT (s2_len, 0); s2_len = 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 = .DEFERRED_INIT (__s2_len, 2); No, __s2_len_218 = .DEFERRED_INIT (__s2_len_217(D), 2); > ? > > > __s2_len_219 = 7; > if (__s2_len_219 <= 3) > goto ; [INV] > else > goto ; [INV] > > : > _1 = (long unsigned int) i_175; > > > ****However, after “ccp”, in “t.i.032t.ccp1”, we have: > > : > __s1_len_217 = .DEFERRED_INIT (__s1_len_176, 2); > __s2_len_218 = .DEFERRED_INIT (7, 2); > _36 = (long unsigned int) i_175; > _37 = _36 * 8; > _38 = argv_220(D) + _37; > > > Looks like that the optimization “ccp” replaced the first argument of the call .DEFERRED_INIT with the constant 7. > This should be avoided. > > (NOTE, this issue existed in the previous patches, however, only exposed with this version since I added more verification > code in tree-cfg.c to verify the call to .DEFERRED_INIT). > > I am wondering what’s 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 - eventually > partial - initialization only. > > If this additional .DEFERRED_INIT will be kept till RTL expansion phase, then it will become a real initialization: > > i.e. > > s2_len = 0; //.DEFERRED_INIT expanded > s2_len = 4; // the original initialization > > Then the first initialization will be eliminated by current RTL optimization 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 “ccp” phase to specially handle calls to .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 Nuernberg, > Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg) > > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)