From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66034 invoked by alias); 20 Nov 2019 22:32:43 -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 66018 invoked by uid 89); 20 Nov 2019 22:32:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=f2018, F2018 X-HELO: mx-relay21-hz1.antispameurope.com Received: from mx-relay21-hz1.antispameurope.com (HELO mx-relay21-hz1.antispameurope.com) (94.100.132.221) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Nov 2019 22:32:41 +0000 Return-Path: Received: from s041.bre.qsc.de ([195.90.7.81]) by mx-relay21-hz1.antispameurope.com; Wed, 20 Nov 2019 23:32:38 +0100 Received: from localhost.localdomain (port-92-195-226-14.dynamic.qsc.de [92.195.226.14]) by s041.bre.qsc.de (Postfix) with ESMTPSA id BE64D2C005A; Wed, 20 Nov 2019 23:32:37 +0100 (CET) Subject: Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures To: Janne Blomqvist , =?UTF-8?Q?Thomas_K=c3=b6nig?= Cc: Thomas Koenig , Tobias Burnus , "fortran@gcc.gnu.org" , gcc-patches 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> From: Tobias Burnus Message-ID: <14e56050-cfd8-f115-ab74-d49f4322754f@net-b.de> Date: Wed, 20 Nov 2019 22:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-cloud-security-sender:burnus@net-b.de X-cloud-security-recipient:gcc-patches@gcc.gnu.org X-cloud-security-Virusscan:CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay21-hz1.antispameurope.com with 30C7A10E39EA X-cloud-security-connect: s041.bre.qsc.de[195.90.7.81], TLS=1, IP=195.90.7.81 X-cloud-security:scantime:.2379 X-SW-Source: 2019-11/txt/msg02045.txt.bz2 On 11/20/19 11:18 PM, Janne Blomqvist wrote: >> Of course, Fortran language rules specify that the call to bar >> cannot do anything to n > Hmm, does it? What about the following modification to your testcase: This code violates (quote from F2018): "15.5.2.13  Restrictions on entities associated with dummy arguments" "While an entity is associated with a dummy argument, the following restrictions hold." "[…] (3)   Action that affects the value of the entity or any subobject of it shall be taken only through the dummy argument unless" "(a) the dummy argument has the POINTER attribute, […]" (Some more related to TARGET attribute and to coarrays, which also do not apply here.) Not listed there, but the asynchronous attribute (Section 8.5.4) would be also a way to disable the optimization we are talking about. Cheers, Tobias > module nmod > integer :: n > end module nmod > > subroutine foo(n,m) > m = 0 > do 100 i=1,100 > call bar > m = m + n > 100 continue > end subroutine foo > > subroutine bar() > use nmod > n = 0 > end subroutine bar > > program main > use nmod > implicit none > integer :: m > n = 1 > m = 0 > call foo(n, m) > print *, m > end program main > > >> So, a copy in / copy out for variables where we can not be sure that >> no value is assigned? Does anybody see a downside for that?) > In principle sounds good, unless my concerns above are real and affect > this case too. > >>> Is there a risk of performance regressions due to higher register pressure? >> I don't think so. Either the compiler realizes that it can >> keep the variable in a register (then it makes no difference), >> or it has to load it fresh from its address (then there is >> one additional register needed). > Yes, true. Good point. > >