On Fri, 2005-04-08 at 12:45 -0400, Diego Novillo wrote: > One of the micro-optimizations I am about to merge from TCB > involves disregarding V_MAY_DEF/V_MUST_DEF operands for read-only > globals. > > So, if a symbol is marked read-only and the operand scanner > requests a V_MAY_DEF or V_MUST_DEF operand for it, we replace it > with a VUSE. > > This works fine, except that I was having comparison errors with > SPEC2000's eon. I tracked it down to the C++ FE emitting an > assignment instruction for a global const variable. What follows > is speculation, I have no idea how the FE really works: > > The source code declares > > const double ggPi = 3.14159265358979323846; > double const divPi = 1 / ggPi; > > And since divPi is initialized to an expression, I guess it needs > to compute it at runtime, so it emits an initialization function:
If the variable is TREE_READONLY, and is assigned, that is wrong. full stop. We have things like TREE_INVARIANT, etc, to try to describe write once and other types of variables. > > I also wouldn't want the FE to mark divPi writeable, as we would > now consider it call-clobbered. This is a symptom of not computing call clobbering at the callgraph level like we should. It really is a call clobbered variable if you consider it on a single-function basis. > Is this analysis correct? Will > other FEs need to do things like this? If so, then I'll just get > rid of this transformation. Your transform is correct. The FE is not. The variable is not read only. It is write once, then read-only. When the IPA pass manager gets reviewed and approved, I will rewrite call-clobbering to be smarter so that we won't call clobber this variable anywhere. :)