From owner-svn-src-head@freebsd.org Fri Jan 19 18:27:04 2018 Return-Path: Delivered-To: svn-src-head@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 To: Conrad Meyer Cc: "Rodney W. Grimes" , src-committers , 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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--