svn commit: r327354 - head/sys/vm

Brooks Davis brooks at freebsd.org
Fri Jan 19 18:27:04 UTC 2018


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 at 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 = 0; i < pages;) { }
> >
> >         for (int i = 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.
> 
> 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.)
> 
> 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.)
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20180119/f45469e0/attachment.sig>


More information about the svn-src-head mailing list