public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Janne Blomqvist <blomqvist.janne@gmail.com>
To: "Thomas König" <tk@tkoenig.net>
Cc: Thomas Koenig <tkoenig@netcologne.de>,
	Tobias Burnus <tobias@codesourcery.com>,
		"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures
Date: Wed, 20 Nov 2019 22:19:00 -0000	[thread overview]
Message-ID: <CAO9iq9F6-F0nkuFRC+edsA7rN3OTKX20L2k87cwQARy1QHipjA@mail.gmail.com> (raw)
In-Reply-To: <4e68f250-1e41-ac7c-dc64-88f91cdf183e@tkoenig.net>

On Wed, Nov 20, 2019 at 11:35 PM Thomas König <tk@tkoenig.net> wrote:
>
> Am 20.11.19 um 21:45 schrieb Janne Blomqvist:
> > BTW, since this is done for the purpose of optimization, have you done
> > testing on some suitable benchmark suite such as polyhedron, whether
> > it a) generates any different code b) does it make it go faster?
>
> I haven't run any actual benchmarks.
>
> However, there is a simple example which shows its advantages.
> Consider
>
>        subroutine foo(n,m)
>        m = 0
>        do 100 i=1,100
>          call bar
>          m = m + n
>   100  continue
>        end
>
> (I used old-style DO loops just because :-)
>
> Without the optimization, the inner loop is translated to
>
> .L2:
>          xorl    %eax, %eax
>          call    bar_
>          movl    (%r12), %eax
>          addl    %eax, 0(%rbp)
>          subl    $1, %ebx
>          jne     .L2
>
> and with the optimization to
>
> .L2:
>          xorl    %eax, %eax
>          call    bar_
>          addl    %r12d, 0(%rbp)
>          subl    $1, %ebx
>          jne     .L2
>
> so the load of the address is missing.  (Why do we zero %eax
> before each call? It should not be a variadic call right?)

Not sure. Maybe some belt and suspenders thing? I guess someone better
versed in ABI minutiae knows better. It's not Fortran-specific though,
the C frontend does the same when calling a void function.

AFAIK on reasonably current OoO CPU's xor'ing a register with itself
is handled by the renamer and doesn't consume an execute slot, so it's
in effect a zero-cycle instruction. Still bloats the code slightly,
though.

> 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:

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.


-- 
Janne Blomqvist

  reply	other threads:[~2019-11-20 22:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-11 21:57 Thomas König
2019-11-11 22:08 ` Thomas Koenig
2019-11-11 22:53 ` Janne Blomqvist
2019-11-11 23:02   ` Thomas König
2019-11-12  7:48     ` Janne Blomqvist
2019-11-12 12:50       ` Thomas König
2019-11-12 14:33         ` Tobias Burnus
2019-11-12 17:22           ` Thomas König
2019-11-15  7:41 ` Tobias Burnus
2019-11-15 18:07   ` Thomas König
2019-11-16 20:42     ` Thomas Koenig
2019-11-19 10:46       ` Bernhard Reutner-Fischer
2019-11-19 23:04         ` Thomas Koenig
2019-11-20 18:00           ` Bernhard Reutner-Fischer
2019-11-20 20:45             ` Janne Blomqvist
2019-11-20 21:07               ` Steve Kargl
2019-11-20 21:35               ` Bernhard Reutner-Fischer
2019-11-20 20:46       ` Janne Blomqvist
2019-11-20 21:39         ` Thomas König
2019-11-20 22:19           ` Janne Blomqvist [this message]
2019-11-20 22:32             ` Janne Blomqvist
2019-11-21  9:35               ` Janne Blomqvist
2019-11-20 22:37             ` Tobias Burnus
2019-11-20 22:41             ` Thomas König
2019-11-20 22:30           ` Tobias Burnus
2019-11-21  9:41           ` Tobias Burnus
2019-11-21 12:30             ` Richard Biener
2019-11-21 13:17               ` Tobias Burnus
2019-11-21 13:37                 ` Tobias Burnus
2019-11-21 14:10                 ` Richard Biener
2019-11-21 14:39                   ` Tobias Burnus
2019-11-22 10:44                     ` Tobias Burnus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAO9iq9F6-F0nkuFRC+edsA7rN3OTKX20L2k87cwQARy1QHipjA@mail.gmail.com \
    --to=blomqvist.janne@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=tk@tkoenig.net \
    --cc=tkoenig@netcologne.de \
    --cc=tobias@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).