From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sourceware.org (Postfix) with ESMTPS id 2F67F38582B0 for ; Fri, 17 Mar 2023 13:55:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F67F38582B0 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=irisa.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irisa.fr Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none X-Ironport-Dmarc-Check-Result: validskip X-IronPort-AV: E=Sophos;i="5.98,268,1673910000"; d="scan'208";a="97777916" Received: from ptb-5cg22835fs.irisa.fr (HELO [131.254.21.198]) ([131.254.21.198]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2023 14:55:09 +0100 Message-ID: Date: Fri, 17 Mar 2023 14:55:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [Tree-SSA] Question from observation, bogus SSA form? To: Martin Jambor , gcc@gcc.gnu.org References: Content-Language: fr, en-US From: Pierrick Philippe In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 16/03/2023 17:30, Martin Jambor wrote: > Hello Pierrick, > > On Thu, Mar 16 2023, Pierrick Philippe wrote: >> Hi everyone, >> >> I was working around with the analyzer, but I usually dump the SSA-tree >> to get a view of the analyzed code. >> This is how I noticed something wrong, at least in the sense of the >> definition of SSA form. > please note that only some DECLs are put into a SSA form in GCC, these > are sometimes referred to as "gimple registers" and you can query the > predicate is_gimple_reg to figure out whether a DECL is one (putting > aside "virtual operands" which are a special construct of alias > analysis, are in an SSA form but the predicate returns false for them > for some reason). > > This means that global variables, volatile variables, aggregates, > variables which are not considered aggregates but are nevertheless > partially modified (think insertion into a vector) or variables which > need to live in memory (most probably because their address was taken) > are not put into an SSA form. It may not be easily possible. Alright, I understand, but I honestly find it confusing. I mean, aren't they any passes relying on the pure SSA form properties to analyze code? For example to DSE or DCE. [stripping] >> The thing is, there is two distinct assignment to the same LHS tree at >> two different gimple statement, which is by definition not supposed to >> happened in SSA form. > I think it is now clear that x is not in SSA form because (at this stage > of the compilation) it is still considered to need to live in memory. I think that I get your point. It would be a heavy design change to be able to write it in pure SSA form. >> Is there any particular reason this happen? Is that because the address >> of x is taken and stored? >> >> I have to precise, I did not dig into the SSA form transformation and am >> a newbie to gcc source code. >> So maybe my question is a bit naive or a known issue. > No worries, we know these important details are not straightforward when > you see them for the first time. > > Good luck with your gcc hacking! Thanks! :) Pierrick