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> In-Reply-To: <CAG6CVpVQqyhub0g-iOjKbZYEaEqAy87WdrocoQ_MxYhvbz1k%2BQ@mail.gmail.com> References: <601ee1a2-8f4e-518d-4c86-89871cd652af@vangyzen.net> <201801191704.w0JH4rgT072967@pdx.rh.CN85.dnsmgr.net> <CAG6CVpVQqyhub0g-iOjKbZYEaEqAy87WdrocoQ_MxYhvbz1k%2BQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180119181845.GB1758>