From owner-svn-src-all@freebsd.org Fri Jan 19 17:25:37 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 A3163EBDE9F; Fri, 19 Jan 2018 17:25:37 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72CC46ACEE; Fri, 19 Jan 2018 17:25:37 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f50.google.com with SMTP id q8so2950793itb.2; Fri, 19 Jan 2018 09:25:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=NqcTeVaRpCAwMDsQ5w0PqBfssSU+XnXlG/ahCDPDHE8=; b=Y0v2eVklV2x8tU64g8A+GfDUsddDgE+sA0N3nVyPsFjJ/PsseW5/NRbCoGXHbZTVRW 9KQ4MxcJFTd6Gqa3LmRFaNz1mzPzGHo2CUOu9/0k9uKCszV4MbAppFqqS1iMZfsCjYo1 j+kv086ON80pxc0fZhKxFnKE4BQiP2NvjF0bCZzlnwY3jHIL5JlCfS70GUQQmSHx4c29 7VQDvaqkd6Bx3eCxdMDwcPJ4rr6fjVytBkI+LX8qPZ5TzAF2eVPdY6ylkJg3DunAHVWc A4wPLs5jVWC09wSa2dqXSjWeLtXfC3+s+ZogVsxg4+YvHO2FWOByM9iab8IDeHyAKK8k Jluw== X-Gm-Message-State: AKwxytd3A245TxhV+0EAPclyqVETvFY/KFdDFjfAQzo1jweGqY6wi5p0 saCuAsRVef+FAsXR9CCr48Ebyhr+ X-Google-Smtp-Source: ACJfBovHLnZMuOdw837C2MgsJ6UefcKYAYWo2PXe7chbZwymUN4dWub9HNdPGSpiU9n89pZaN3iwJw== X-Received: by 10.36.164.6 with SMTP id z6mr31240599ite.2.1516382735830; Fri, 19 Jan 2018 09:25:35 -0800 (PST) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id q136sm3449700ioe.34.2018.01.19.09.25.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 09:25:35 -0800 (PST) Received: by mail-it0-f42.google.com with SMTP id 196so2935273iti.5; Fri, 19 Jan 2018 09:25:35 -0800 (PST) X-Received: by 10.36.114.193 with SMTP id x184mr31592438itc.71.1516382735327; Fri, 19 Jan 2018 09:25:35 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.95.152 with HTTP; Fri, 19 Jan 2018 09:25:34 -0800 (PST) In-Reply-To: <201801191704.w0JH4rgT072967@pdx.rh.CN85.dnsmgr.net> References: <601ee1a2-8f4e-518d-4c86-89871cd652af@vangyzen.net> <201801191704.w0JH4rgT072967@pdx.rh.CN85.dnsmgr.net> From: Conrad Meyer Date: Fri, 19 Jan 2018 09:25:34 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r327354 - head/sys/vm To: "Rodney W. Grimes" Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Fri, 19 Jan 2018 17:25:37 -0000 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 t= his 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 =E2=80=94 they always determine t= he 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. Best, Conrad [0]: https://en.wikipedia.org/wiki/Live_variable_analysis [1]: https://en.wikipedia.org/wiki/Register_allocation