From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hubicka@kam.mff.cuni.cz>
Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16])
 by sourceware.org (Postfix) with ESMTPS id 903763858407
 for <gcc-patches@gcc.gnu.org>; Thu,  7 Apr 2022 12:58:43 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 903763858407
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)
 id 5019A280BD6; Thu,  7 Apr 2022 14:58:42 +0200 (CEST)
Date: Thu, 7 Apr 2022 14:58:42 +0200
From: Jan Hubicka <hubicka@kam.mff.cuni.cz>
To: Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Fix wrong code in gnatmake
Message-ID: <Yk7gAhA4uVngJ91u@kam.mff.cuni.cz>
References: <Yk7KXSeQ3UmLmMzV@kam.mff.cuni.cz>
 <r9o1qo4p-6qp5-s062-1595-p7n42372ps49@fhfr.qr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <r9o1qo4p-6qp5-s062-1595-p7n42372ps49@fhfr.qr>
X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,
 SPF_NONE, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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 <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2022 12:58:45 -0000

> On Thu, 7 Apr 2022, Jan Hubicka wrote:
> 
> > Hi,
> > this patch fixes miscompilation of gnatmake.  Modref attempts to track memory
> > accesses relative to the base pointers which are parameters of functions.
> > If it fails, it still makes difference between unknown memory access and
> > global memory access.  The second makes it possible to disambiguate with
> > memory that is not accessible from outside world (i.e. everything that does
> > not escape from the caller function).  This is useful so we do not punt
> > when unknown function is called.
> > 
> > Now I added ref_may_access_global_memory_p to tree-ssa-alias whic is using
> > ptr_deref_may_alias_global_p.  There is however a shift in meaning of this
> > predicate: the second tests that the dereference may alias with global variable.
> > 
> > In the testcase we are disambiguating heap allocated escaping memory which is
> > not a global variable but it is still a global memory in the modref's sense.
> > So we need to test in addition contains_escaped.
> > 
> > The patch simply copies logic from the predicate and adds the check.  
> > I am not sure if there is better way to handle this?
> 
> I'm testing the following variant which exposes this detail
> (escaped local memory global or not) in the APIs that say "global"
> which allows to remove ref_may_access_global_memory_p.

Thank you.  Indeed it is better to have an explicit flag, since the
clash of names is bit sensitive. 

Honza