From owner-svn-src-all@freebsd.org Fri Jan 19 18:27:04 2018
Return-Path: <owner-svn-src-all@freebsd.org>
Delivered-To: svn-src-all@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97E72EC062A;
Fri, 19 Jan 2018 18:27:04 +0000 (UTC)
(envelope-from brooks@spindle.one-eyed-alien.net)
Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net
[199.48.129.229])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4E4336D31F;
Fri, 19 Jan 2018 18:27:04 +0000 (UTC)
(envelope-from brooks@spindle.one-eyed-alien.net)
Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001)
id 5B4C15A9F27; Fri, 19 Jan 2018 18:18:45 +0000 (UTC)
Date: Fri, 19 Jan 2018 18:18:45 +0000
From: Brooks Davis <brooks@freebsd.org>
To: Conrad Meyer <cem@freebsd.org>
Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>,
src-committers <src-committers@freebsd.org>,
svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject: Re: svn commit: r327354 - head/sys/vm
Message-ID: <20180119181845.GB1758@spindle.one-eyed-alien.net>
References: <601ee1a2-8f4e-518d-4c86-89871cd652af@vangyzen.net>
<201801191704.w0JH4rgT072967@pdx.rh.CN85.dnsmgr.net>
<CAG6CVpVQqyhub0g-iOjKbZYEaEqAy87WdrocoQ_MxYhvbz1k+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF"
Content-Disposition: inline
In-Reply-To: <CAG6CVpVQqyhub0g-iOjKbZYEaEqAy87WdrocoQ_MxYhvbz1k+Q@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: svn-src-all@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: "SVN commit messages for the entire src tree \(except for "
user" and " projects" \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-all>,
<mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-all>,
<mailto:svn-src-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jan 2018 18:27:04 -0000
--h31gzZEtNLTqOjlF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 19, 2018 at 09:25:34AM -0800, Conrad Meyer wrote:
> On Fri, Jan 19, 2018 at 9:04 AM, Rodney W. Grimes
> <freebsd@pdx.rh.cn85.dnsmgr.net> wrote:
> > BUT I do not believe this bit of "style" has anything to do with
> > readability of code, and has more to do with how code runs on a
> > processor and stack frames. If you defer the declaration of
> > "int i" in the above code does that compiler emmit code to allocate
> > a new stack frame, or does it just add space to the function stack
> > frame for this?
> >
> > What happens if you do
> > for (int i =3D 0; i < pages;) { }
> >
> > for (int i =3D 1; i < pages;) { }
> > as 2 seperate loops, do we allocate 2 i's on the stack at
> > function startup, or do we defer and allacte each one
> > only when that basic block runs, or do we allocate 1 i
> > and reuse it, I know that the compiler makes functional
> > code but how is that functionality done? The current
> > style leaves no doubt about how things are done from
> > that perspective.
>=20
> Modern (and I'm using that word very loosely here ??? think GCC did this
> 10+ years ago) optimizing compilers do something called liveness
> tracking[0] for variables to determine the scope they are used in
> (something like the region between last write and last read). So in
> that sense, optimizing compilers do not care whether you declare the
> variable at function scope or local scope ??? they always determine the
> local scope the variable is alive in. (Other than for shadowing,
> which we strongly discourage and is considered bad style.)
>=20
> Liveness analysis is part of register allocation[1], which typically
> uses a graph coloring algorithm to determine the minimal number of
> distinct registers needed to hold live values. If the number of
> registers needed is more than the machine provides, some values must
> be spilled to the stack. (On modern x86 it doesn't matter too much
> what you spill to the stack, because the top few words of the stack
> region is actually quite fast, but clever compilers targeting other
> platforms may attempt to spill less frequently accessed values.)
>=20
> I think I recall Clang and other LLVM frontends do something nutty
> when they emit intermediary representation, like using a new register
> for each assignment. This relies on the register allocater to reduce
> that to something sane for the target machine.
LLVM uses static single assigment for non-memory values (which the i's
above are unless someone takes a reference to them or the register
allocator needs to spill them.) In SSA every assignment results in a
new register in the IR.
-- Brooks
https://en.wikipedia.org/wiki/Static_single_assignment_form
--h31gzZEtNLTqOjlF
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJaYjaEAAoJEKzQXbSebgfALDwH/R86off+LcmcbYLxMcdo/ZXc
9j9X7HhBQkuU+uQT2L5G9VTfe+3XnpUgAC5R0xj1WVfnrkHv91enL3nHqtrFh1uy
j9kyIuPkLTNmHdLmoZM8A/c5iFkkIrsggxS+2fK/okBveKQw5ghskFs7KtzZniiV
6aI8bpubCkpzOykFYO/jNjMUCuZtZnIWyS24RODBI8bOqpfS0PBxqgFro26oQ9U9
YTuAzHk677S/pViyo8hX1c/a9Vei3ejrzjgJHj8zbwrqNx32hwa7TKmQYu6A+77l
HR62Fz2yCNBXwhX6GhYzj17gUr2d5mhNctFa8oLRvGZHYPyOpNZpPTeGWJrfN9k=
=6AJd
-----END PGP SIGNATURE-----
--h31gzZEtNLTqOjlF--