From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58520 invoked by alias); 21 Nov 2019 14:10:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 58497 invoked by uid 89); 21 Nov 2019 14:10:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*RU:209.85.208.195, HX-Spam-Relays-External:209.85.208.195 X-HELO: mail-lj1-f195.google.com Received: from mail-lj1-f195.google.com (HELO mail-lj1-f195.google.com) (209.85.208.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Nov 2019 14:10:00 +0000 Received: by mail-lj1-f195.google.com with SMTP id e9so3321518ljp.13; Thu, 21 Nov 2019 06:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1YBWLjhOgqcdLDahPCwPGrFlPmC9hg2Tv/qdJyoRJdU=; b=LgS9K0WmbmMXQ+1g+YWRDvEqcGpStfGlAeRrGFxaCut+5AA0hi5Ba5aHqsOYL+70kS vud+SISvscexlRwrdQSJzpRmXb9aaFblkdF92jhgqnyDIByLxlTr0GXlHzb2cEA2xYcF 7dEc000xjRTvaqSWf8pHxi05GeBp5At9KnzDIXbVuHmE+YVzdo50OU4d+Z5iSVvih5BV FQZzKrHolCYB6My60m7NZ1BrxJSqgV+/dBC/pXDPtWKNerSVpd3COfgd5as3ZYWsGu3E 5a6AXHzeNO4DndmQER7BiiGXHUbRRgB0ZNAdlU3kGlzhEPip6XD9oD2iMngodQrc+rQ3 xNDw== MIME-Version: 1.0 References: <48286910-ebbb-10e4-488b-8c96e505375c@tkoenig.net> <43b9fcf0-f457-90a7-c807-4aebc65cb045@tkoenig.net> <2981fd67-007e-7327-8208-27e8fd18d9db@netcologne.de> <4e68f250-1e41-ac7c-dc64-88f91cdf183e@tkoenig.net> <4ecba99c-f63a-628c-0778-d651503f7aa6@codesourcery.com> <64ac7298-7589-79dc-9ce8-8f801c247b55@codesourcery.com> In-Reply-To: <64ac7298-7589-79dc-9ce8-8f801c247b55@codesourcery.com> From: Richard Biener Date: Thu, 21 Nov 2019 14:10:00 -0000 Message-ID: Subject: Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures To: Tobias Burnus Cc: =?UTF-8?Q?Thomas_K=C3=B6nig?= , Janne Blomqvist , Thomas Koenig , "fortran@gcc.gnu.org" , gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg02106.txt.bz2 On Thu, Nov 21, 2019 at 2:16 PM Tobias Burnus wro= te: > > Hi Richard, > > On 11/21/19 1:16 PM, Richard Biener wrote: > > OK, so I found it, it's handled via SSA_NAME_POINTS_TO_READONLY_MEMORY > > which is initialized during the rewrite into SSA form from the > > information given by the "fn spec" attribute [=E2=80=A6] so when the fr= ontend > > sets "fn spec" from the intent it should already work. > > Which I can confirm for the following made-up example: > > real function foo(n) > implicit none (type) > integer, intent(in) :: n > integer :: i > foo =3D 0.5 > if (n /=3D 0) return > call bar() > do i =3D 1, n > foo =3D foo + sin(foo) > end do > end > > The optimized dump shows the following, i.e. GCC nicely optimizes both th= e loop and the 'sin' call away: > > foo (integer(kind=3D4) & restrict n) > { > integer(kind=3D4) _1; > [local count: 241635843]: > _1 =3D *n_9(D); > if (_1 !=3D 0) > goto ; [51.12%] > else > goto ; [48.88%] > > [local count: 118111600]: > bar (); > > [local count: 241635844]: > return 5.0e-1; > } > > I think this optimization permits some crucial optimizations. > I have not fully followed the later versions of the patch whether > they exploit some additional language semantics to permit optimizations > even without intent(in), but the initial discussion started with intent(i= n). > > > But the examples I saw above didn't use INTENT(IN) for the scalar > > parameters. > > I concur that a well-written program should make use of intent(in) where > sensible. > > There are cases, which could be optimized likewise =E2=80=93 but based on= the > case that the pointer address cannot escape instead of just assuming > that the argument cannot change. =E2=80=93 The question is how to convey = this to > the middle end. > > I wonder whether there is a 'fn attr' which can tell that the first > argument of 'print_i' does not cause the address of 'i' escape. If so, > one could mark all procedure arguments such =E2=80=93 unless they have the > pointer, target or asynchronous attribute or are coarrays. [Probably > needs some fine tuning.] > > In this example, variable values do change, but only in a controlled way > ('print_i' could change it, 'bar' cannot). The semantic is also mainly a > property of the (local) variable (or dummy argument) declaration and not > of the functions which are called =E2=80=93 although, if 'i' has no target > attribute, print_i's argument cannot have neither =E2=80=93 hence, one co= uld > generated a function interface > > real function foo(i, y) > implicit none (type) > integer :: i > real :: y > foo =3D 0.0 > call print_i(i) > i =3D 5 > call bar() ! < this prevents optimizing the sin(y) away > if (i =3D=3D 5) return > foo =3D sin(y) > end > > Fortran semantics implies that 'i' can only change after the 'i =3D 5' if: > 'i' has the TARGET (or POINTER) attribute. Or it is possible if 'i' has > the ASYNCHRONOUS or VOLATILE attribute =E2=80=93 or it is a coarray (wher= e a > remote image can modify the local value). So I think what you'd need to do is make 'i' marked as TYPE_RESTRICT then. I think we don't yet handle it but it means that bar() may not modify 'i' but via 'i' (but it doesn't get 'i' as a parameter). > For asynchronous, it would be something like "call read_i(i); call > wait()" which is structurally the same as above. > > TARGET: "An object without the TARGET attribute shall not have a pointer > associated with it." > VOLATILE: "may be referenced, defined, or become undefined, by > means20not specified by the program" > ASYNCHRONOUS: "An entity with the ASYNCHRONOUS attribute is a variable, > and may be subject to asynchronous input/output or asynchronous > communication." I think for GIMPLE everything not obviously on the stack is ASYNCHRONOUS. Richard. > Tobias >