Hello,
I had a look at the global variable optimizer. In my opinion it
handles a few special cases, when global variables can be replaced by
local variables or be removed completely. Basically I think that this
problem could be solved with an interprocedural live value analysis
for global variables more generally. An assignment to a global
variable can be removed, if this global variable is dead at this
assignment. I know that this kind of analysis is not trivial to
implement and may have a significant performance impact. However it
might be useful.
What is your opinion about this analysis and transformation? Am I
right regarding the usefulness and the effort? What level of precision
would be reasonable (e.g. the depth of a calling context or no context
sensitivity at all)? What kind of fixpoint solver would be the best
choice for this purpose? Are their any reasons against my proposal?
Kind regards,
Gordon
Hello,
I had a look at the global variable optimizer. In my opinion it
handles a few special cases, when global variables can be replaced by
local variables or be removed completely. Basically I think that this
problem could be solved with an interprocedural live value analysis
for global variables more generally. An assignment to a global
variable can be removed, if this global variable is dead at this
assignment. I know that this kind of analysis is not trivial to
implement and may have a significant performance impact. However it
might be useful.
What is your opinion about this analysis and transformation?
I'm a bit skeptical that it will have widespread impact, but it is very hard to tell and more surprising things have been discovered 
Am I
right regarding the usefulness and the effort? What level of precision
would be reasonable (e.g. the depth of a calling context or no context
sensitivity at all)? What kind of fixpoint solver would be the best
choice for this purpose? Are their any reasons against my proposal?
I'd suggest by starting simple: find a case that you think the transform should handle (ideally in real world code) and build it up to be sufficient to handle that one case. When you have that, run it on a variety of code to see what else it kicks in on. If it is looking promising, keep incrementally making it smarter.
Once you have something that works, we can evaluate whether it makes sense to turn it on by default. This is a balance between how much improvement it gives vs the compile time cost.
-Chris