|Global versus Stack variables email@example.com (shrey) (2005-11-19)|
|Re: Global versus Stack variables firstname.lastname@example.org (email@example.com) (2005-11-21)|
|Re: Global versus Stack variables firstname.lastname@example.org (glen herrmannsfeldt) (2005-11-21)|
|Re: Global versus Stack variables email@example.com (2005-11-21)|
|Re: Global versus Stack variables firstname.lastname@example.org (2005-11-21)|
|Re: Global versus Stack variables email@example.com (Jatin Bhateja) (2005-11-26)|
|Re: Global versus Stack variables firstname.lastname@example.org (2005-11-26)|
|Re: Global versus Stack variables email@example.com (Dave Thompson) (2005-12-05)|
|From:||glen herrmannsfeldt <firstname.lastname@example.org>|
|Date:||21 Nov 2005 22:43:07 -0500|
> I was wondering if ppl can give their opinion on the following
> question. What is the impact of a variable being a global or a local
> variable on optimizations. In other words, is it likelier to produce
> better code if a variable is local than global. The reason I ask this
> is I wonder if register allocation is harder if a variable is global
> instead of local. Are there other optimizations which get affected due
> to this consideration.
> [It depends on your language, but in languages with pointers, the
> biggest advantage of stack locals is that the compiler can assume
> no aliasing of stack variables that haven't had their address taken.
Note that Fortran assumes no aliasing in many cases where other
languages might not make that assumption. One common and confusing
case is multiple parameters to the same subroutine, where the compiler
is allowed to assume that they are not aliased.
Fortran does pointers different than other languages, so I am not sure
about the aliasing rules in that case.
As far as execution time, on some machines it takes more instructions,
or more machine cycles to reference a global variable, where they are
indirectly addressed using the appropriate code sequence. That takes
an extra register on some machines. (Load address of variable into a
register, then operate on the value addressed by the register.)
Return to the
Search the comp.compilers archives again.