From owner-svn-src-all@freebsd.org Sat Jan 20 07:17:21 2018 Return-Path: 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 E2731EBF76E; Sat, 20 Jan 2018 07:17:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3696C07E; Sat, 20 Jan 2018 07:17:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 6DDF5429487; Sat, 20 Jan 2018 18:17:10 +1100 (AEDT) Date: Sat, 20 Jan 2018 18:17:10 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org 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 In-Reply-To: Message-ID: <20180120154359.R1063@besplex.bde.org> References: <601ee1a2-8f4e-518d-4c86-89871cd652af@vangyzen.net> <201801191704.w0JH4rgT072967@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=DIX/22Fb c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=nlC_4_pT8q9DhB4Ho9EA:9 a=iKhvJSA4AAAA:8 a=agQyd4kqTVSkE4UJnTUA:9 a=1CyblWcE2CtPoiIb:21 a=sFibIJslb0rysKLk:21 a=45ClL6m2LaAA:10 a=odh9cflL3HIXMm4fY7Wr:22 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 07:17:22 -0000 On Fri, 19 Jan 2018, 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. > > Modern (and I'm using that word very loosely here =E2=80=94 think GCC did= this > 10+ years ago) optimizing compilers do something called liveness gcc-1 did this 25 years ago (if not 30 years ago). > 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 =E2=80=94 they always determine= the > local scope the variable is alive in. (Other than for shadowing, > which we strongly discourage and is considered bad style.) gcc did this more primitively 25 years ago, but it always (except for alloca(3)) allocated space for all variables in a function on entry to the function (except for alloca(3)). -O0 doesn't do much more than allocate all variables on the stack. -O moves a few variables to registers. Debugging is also easier with all variables on the stack, allocated to fixed positions with a lifetime extending to the end of the function. gcc does many minor pessimizations, at least with -O, so that -g mostly works. clang does the opposite, so that -O -g mostly doesn't work (it tends to give "value optimized out" even for args). Debugging is another reason to declare all variables at the start of functions. If you reuse a function-scope loop variable named i, then you can't see what its value was for previous loops in the function, but you can at least write "display" and "watch" directives for it without these breaking by the variable going out of scope before the end of the function. > 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.) Not usually the top. Variables that can't be kept entirely in registers are usually allocated at a fixed place in the stack which is not especially likely to be at the top. Caching works the same everywhere on the stack. Sometimes related variables end up in the same cache line so that caching works best, but doing this intentionally is much harder than register allocation. > 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. gcc also depends on the register allocator to undo initial intentionally very stupid allocation. New (physical) registers should be used whenever possible to maximize use of CPU resources. Bruce From owner-svn-src-all@freebsd.org Sat Jan 20 08:58:04 2018 Return-Path: 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 E8947EC3C4B; Sat, 20 Jan 2018 08:58:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 6F79E6F2FB; Sat, 20 Jan 2018 08:58:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id CB4AA1047A3A; Sat, 20 Jan 2018 19:57:55 +1100 (AEDT) Date: Sat, 20 Jan 2018 19:57:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Don Lewis cc: cem@freebsd.org, "Rodney W. Grimes" , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328159 - head/sys/modules In-Reply-To: Message-ID: <20180120183216.U1478@besplex.bde.org> References: <201801191737.w0JHbM90073097@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=DIX/22Fb c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=iKhvJSA4AAAA:8 a=je3P-fZqYKzYcMC0QtAA:9 a=CjuIK1q_8ugA:10 a=odh9cflL3HIXMm4fY7Wr: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" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 08:58:05 -0000 On Fri, 19 Jan 2018, Don Lewis wrote: > On 19 Jan, Conrad Meyer wrote: >> On Fri, Jan 19, 2018 at 9:37 AM, Rodney W. Grimes >> wrote: >>> If you think in assembler it is easy to understand why this is UB, >>> most (all) architectures Right Logic or Arithmetic Shift only accept an >>> operand that is a size that can hold log2(wordsize). The not-unused x86 arch is one that does this. IIRC, some history of this is: - on the 8086, the shift count was taken mod 32. 16 bits was enough for anyone, and shifting left or right by 16 through 31 (but not by 32) shifted out all of the bits (in the unsigned case) to give 0. - for the 80386, someone forgot why the 8086 took the count mod 32 instead of just 16, and kept using 32. 16 bits was not enough for anyone, and shifting left or right by 32 had no effect (even in the signed case?). C was standardized at much the same time as the 80386 came out, so shifting right by 32 was not required to work. It gave undefined behaviour. Optimizing compilers took advantage of the UB to give the same do-nothing behaviour as the hardware for shift counts of 32 (or do-something-strange-and-undocumented for larger shift counts). Pessimizing compilers could have taken advantage of the UB to shift out all of the bits in the sme way at runtime as at compile time like some programmers expect. This would pessimize the usual case (extra code would be needed when the produce 0 at runtime when the shift count is >= 32). - binary compatibility prevented anyone fixing this on 32-bit x86's - modulo 32 is no good for 64-bit mode. Either someone forgot about the 8086 again, or there is some binary compatibility problem that inhibited expanding 32 to 128 or "infinity". (It certainly can't be "infinity" because even INT16_MAX is unreachable due to the shift count being limited to 256 by the old mistake^Woptimization of keeping it in %cl.) - binary compatibilty prevented fixing this on 64-bit x86's in 32-bit mode. >> This is a logical right shift by a constant larger than the width of >> the left operand. As a result, it would a constant zero in any >> emitted machine code. It is a bug in the C standard and a concession >> to naive, non-optimizing compilers that this is considered UB. This isn't a logical right shift, but it is what the hardware does. It is a feature in the C standard and a concession to smart, optimizing compilers that this is UB. UB allows the compiler to do anything, including optimizing to do what the hardware does or pessimizing to give logical shifts. It is interesting that the behaviour is undefined even for unsigned left operands. UB is not strictly required. The behaviour could also be implementation defined or perhaps unspecified. This makes little difference in practice. It is unclear if the implementation can define the behaviour as back to undefined. > Generating one answer when compiler knows that everything is constant > and can figure out the "correct" value at compile time, but generating > an entirely different answer when the shift value is still constant, but > passed in as a function parameter and hides that information from the > compiler so the result is generated at runtime sounds like a good way to > introduce bugs. My pre-C90 compiler does this for integer division. C99 requires incorrect rounding (round towards 0 instead of towards -infinity for positive divisors), but my compiler does correct rounding for divisions done at compile time and in software and whatever the hardware does (usually incorrect) otherwise. In C90, the rounding is implementation- defined, so it can even be correct, but in practice it cannot be trusted. Bruce