Re: a question about const and pure functions.

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Geoffrey Keating wrote:

> On 10/11/2004, at 11:06 AM, Kenneth Zadeck wrote:
>
> > Do we mark functions being const or pure (TREE_READONLY or 
> > DECL_IS_PURE) based on some external standard definition or are these 
> > defined any way that the gcc community feels is good?
>
>
> There are backwards compatibility issues, of course, but they're not 
> based on any particular standard.
>
> > I am in the process of moving the code that does this analysis so 
> > that it is done very early and at once for the entire compilation 
> > unit.  There appear to be a few minor bugs in the code as well as a 
> > few missed opportinities.  But before I was going to make any 
> > changes, I was wondering if there was any better standard of 
> > definition beyond what is defined in doc/extend.texi.
>
>
> No, I don't think there's anything beyond the documentation.  I think 
> the documentation could do with being made more precise, but it's not 
> very bad.
The minor bugs and missed opportunities are associated with the code 
that controls the pure can call pure and const and const can call const 
put const cannot call pure.  The code is messed up in both ways.  Some 
const calling pures are allowed (if the pure has no args) and some pure 
calls consts are rejected.  These could be fixed in the existing code, 
but there are other issues with performing this analysis at the rtl level.

The extensions that I want to add are:

1) allow const to access memory if the memory is a constant, i.e. if you 
have a readonly static with a decl initial that satisfies  
is_gimple_min_invariant (), such a reference need not be treated 
differently than referencing a "5".

2) move the processing earlier so that it is available to the rest of 
the compiler.

3) allow for recursive and mutually recursive pure and const functions.

4) eventually to allow some loops (if they can be proven to be finite) 
rather than just looking for back edges in the cfg. We have this 
analysis in the compiler, we should be allowed to use the info here.

The hope here is that with the exception of setting errno, that most 
small table driven mathematical functions would fall into one of these  
categories.

Kenny