svn commit: r362217 - head/stand/common

[Alexander Richardson]

On Tue, 16 Jun 2020 at 18:09, Cy Schubert <Cy.Schubert at cschubert.com> wrote:
>
> In message <55903c38d363aef2a6f6d0075dd4526b86d51258.camel at freebsd.org>,
> Ian Le
> pore writes:
> > On Tue, 2020-06-16 at 07:05 +0000, Toomas Soome wrote:
> > > Author: tsoome
> > > Date: Tue Jun 16 07:05:03 2020
> > > New Revision: 362217
> > > URL: https://svnweb.freebsd.org/changeset/base/362217
> > >
> > > Log:
> > >   loader: variable i is unused without MBR/GPT support built in
> > >
> > >   Because i is only used as index in for loop, declare it in for
> > > statement.
> > >
> >
> > As much as I prefer doing it this way, style(9) doesn't allow for
> > variable declarations inside a for() statement (or even inside a local
> > block, which is just too 1980s for me, but it is still our standard).
>
> Doesn't this use stack for a shorter period of time or does the compiler
> optimize this, making this change moot?
>
> The tradeoff is a few extra bytes of stack for a longer period of time vs a
> few extra instructions incrementing and decrementing the stack pointer.
>
>
At least for LLVM it makes no difference where you declare the
variable: it will always be represented by an alloca instruction at
the start of the IR function:
https://godbolt.org/z/NFG3hN
There will also not be any changes to the stack pointer since the
stack frame size is fixed no matter where the variables are declared
(unless you use variable-length arrays or __builtin_alloca()).

LLVM will also merge variables that have non-overlapping lifetimes to
reuse the same stack slot if possible.
I'm almost certain GCC performs the same optimizations (as will any
other compiler written in the last 20 years).

Alex