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.
:)

Reply via email to