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 AE3D63858415 for ; Fri, 5 Apr 2024 13:44:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AE3D63858415 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=irisa.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irisa.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AE3D63858415 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=192.134.164.83 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712324673; cv=none; b=rROC0KC7iNWLYjwh2d4l9yTfG+SZ1DES+uRVb1CKOan2wUxutqerP8HnvjywkMU2Rg2adpBrRxxIUd4W9QXeizQQTuz1OJmfJ9yw56NKoo6GmFa1/iBWA/At/rQmB/JVSzhbyGKtioD8cdcQ9Jd0pJev0/k4pkV+XpnuxRq0jPg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712324673; c=relaxed/simple; bh=juDQge1C6QPBmSnYcnA6FeGNb69HbvarPO8HfajNY/Q=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=SHpH4yftpZoTJL+jnwydKIXVh7+zrYprMaVuk8aeRdt5+1aDCgsyEI9jXQsaqrZvkTpzVipwwHHu5X615wtAggTnr2fNasp63ifPXlBd4gu2T109BkPnV0dgfPSxEFX3lOfOjJ7JfVF6c9q04fFsPsJdkh1LX2OGd03eOflkAmQ= ARC-Authentication-Results: i=1; server2.sourceware.org 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="6.07,181,1708383600"; d="scan'208,217";a="160172011" Received: from me099011.etu.univ-rennes1.fr (HELO [10.41.43.110]) ([148.60.99.11]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2024 15:44:30 +0200 Content-Type: multipart/alternative; boundary="------------9LwM80RdCnPobe0W2afZ0P30" Message-ID: Date: Fri, 5 Apr 2024 15:44:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gimple-ssa] result_decl and ssa_name To: Richard Biener Cc: gcc@gcc.gnu.org References: <7b63c4ff-b32e-44ad-9b25-3f8f2d138056@irisa.fr> Content-Language: fr, en-US From: Pierrick Philippe In-Reply-To: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,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: This is a multi-part message in MIME format. --------------9LwM80RdCnPobe0W2afZ0P30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/04/2024 14:46, Richard Biener wrote: > On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe > wrote: >> Hi all, >> >> I do have a question regarding ssa_name and result_decl. >> >> For example on the following gimple function: >> >> int f () >> { >> int x; >> int D.2747; >> int _2; >> >> : >> x_1 = 42; >> _2 = x_1; >> >> : >> : >> return _2; >> >> } >> >> On the above example, using the macro SSA_NAME_VAR() on _2 does not >> yield anything usable. >> Neither to call ssa_default_def() on the result of the result_decl >> obtain through macro DECL_RESULT(). >> >> Is there a way to get the ssa_name corresponding to the result_decl of a >> function obtained through the use of macro DECL_RESULT() on a fn_decl? >> And/or the other way around? I.e., from the returned ssa_name of a >> function to the result_decl of that function? >> >> I totally might be missing something here, but I cannot figure out what. > DECL_RESULT isn't always used (as in your example). Not all SSA names > have corresponding declarations, we have "anonymous" SSA names which > have a NULL_TREE SSA_NAME_VAR (such as the _2 in your example). I see, that makes so much more sense to me now. > What do you try to find in the end? If you want to find all returns you can > walk predecessors of EXIT_BLOCK and look at their last stmt whether they > are greturn statements. I am implementing a state_machine within the analyzer, and I am trying to understand where would be the best place to propagate the state of the return value. I intuitively thought it would be best to do so in the state_machine::on_pop_frame() method, which is called by the analyzer between the two frames of the caller and the callee. What I do have access to is the struct function of the callee/caller, the gcall instruction in the caller and the callee have been processed by my analysis. And to illustrate, here I do have the _2 ssa_name and its state which I know in that case should be propagate to the lhs of the caller gcall instruction. Again I might be taking this in a wrong way. > Richard. >> Thanks for your time, >> >> Pierrick --------------9LwM80RdCnPobe0W2afZ0P30--