From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=IBRF=7I=irisa.fr=pierrick.philippe@sourceware.org>
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by sourceware.org (Postfix) with ESMTPS id 113A33858D35
	for <gcc@gcc.gnu.org>; Thu, 16 Mar 2023 15:26:50 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 113A33858D35
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: mail3-relais-sop.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,265,1673910000"; 
   d="scan'208,217";a="50402494"
Received: from ptb-5cg22835fs.irisa.fr (HELO [131.254.21.198]) ([131.254.21.198])
  by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2023 16:26:49 +0100
Content-Type: multipart/alternative;
 boundary="------------F9V27cf1ilNhpXCxESLpFTN7"
Message-ID: <d89b8539-d41f-18fc-1f36-83bcaab772e8@irisa.fr>
Date: Thu, 16 Mar 2023 16:26:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
To: gcc@gcc.gnu.org
Content-Language: fr, en-US
From: Pierrick Philippe <pierrick.philippe@irisa.fr>
Subject: [Tree-SSA] Question from observation, bogus SSA form?
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,BODY_8BITS,HTML_MESSAGE,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: <gcc.gcc.gnu.org>

This is a multi-part message in MIME format.
--------------F9V27cf1ilNhpXCxESLpFTN7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.

I'm using a version of gcc build from a /trunk/ branch (/20230309/).

Here is an example code:

'''
int main(void) {
     int x = 42;
     int * y = &x;
     x = 6;
     return x;
}
'''

And here is the output from -fdump-tree-ssa-vops:

'''
;; Function main (main, funcdef_no=0, decl_uid=2739, cgraph_uid=1, 
symbol_order=0)

int main ()
{
   int * y;
   int x;
   int D.2744;
   int _5;

   <bb 2> :
   # .MEM_2 = VDEF <.MEM_1(D)>
   x = 42;                                           // First assignment 
to var_decl x
   y_3 = &x;
   # .MEM_4 = VDEF <.MEM_2>
   x = 6;                                             // Second 
assignment to var_decl x
   # VUSE <.MEM_4>
   _5 = x;
   # .MEM_6 = VDEF <.MEM_4>
   x ={v} {CLOBBER(eol)};

   <bb 3> :
<L1>:
   # VUSE <.MEM_6>
   return _5;

}
'''

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.
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.

Thank you for your time,

Pierrick

--------------F9V27cf1ilNhpXCxESLpFTN7--