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 > <free...@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
signature.asc
Description: PGP signature