From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 7EA993857C54; Mon, 21 Sep 2020 07:55:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7EA993857C54 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rguenther@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3269DB276; Mon, 21 Sep 2020 07:56:26 +0000 (UTC) Date: Mon, 21 Sep 2020 09:55:50 +0200 (CEST) From: Richard Biener To: Jan Hubicka cc: =?ISO-8859-2?Q?David_=C8epel=EDk?= , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Subject: Re: New modref/ipa_modref optimization passes In-Reply-To: <20200921074752.GD91738@kam.mff.cuni.cz> Message-ID: References: <157394261677.27454.2367573047582814412@a285.localdomain> <20200919223255.GA69342@kam.mff.cuni.cz> <20200920061551.GA29500@kam.mff.cuni.cz> <20200921074752.GD91738@kam.mff.cuni.cz> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 07:55:52 -0000 On Mon, 21 Sep 2020, Jan Hubicka wrote: > > On Sun, 20 Sep 2020, Jan Hubicka wrote: > > > > > Hi, > > > this is patch I am using to fix the assumed_alias_type.f90 failure by > > > simply arranging alias set 0 for the problematic array descriptor. > > > > There's no such named testcase on trunk. Can you be more specific > > as to the problem at hand? It looks like gfortran.dg/assumed_type_9.f90 > > execute FAILs at the moment. > > > > In particular how's this not an issue w/o IPA modref? > > > > > For TYPE(*) I think the object itself cannot be accessed but for > > arrays the meta-info in the array descriptor can. Now my question > > would be why the Fortran FE at the call site does not build an > > appropriately typed array descriptor? > > > > CCing the fortran list. > > The problem is: > > alsize (struct array15_unknown & restrict a) > { > ... > _2 = *a_13(D).dtype.rank; > _3 = (integer(kind=8)) _2; > ... > } > } > and in main: > > struct array02_integer(kind=4) am; > : > MEM [(struct dtype_type *)&am + 24B] = {}; > am.dtype.elem_len = 4; > am.dtype.rank = 2; > am.dtype.type = 1; > ... > _52 = alsize (&am); > > Here array15_unknown and array02_integer are different structures with > different canonical types and thus we end up disambiguating the accesses > via base alias sets. > > My understanding is that this _unknown array descriptor is supposed to > be universal and work with all kinds of arrays. But the FE builds a new descriptor for each individual call and thus should build a universal descriptor for a call to an universal descriptor argument. Richard. > Wihtout modref this works because alsize is not inlined (we think code > size would grow). Forcing inliner to inline stil leads to working code > because we first constant propagate the pointer and then we see accesses > from same base DECL thus bypass the TBAA checks. Disabling the > constant propagation leads to wrong code as wel. > > Honza > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imend