This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: a question about const and pure functions.
>
>
> 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.
This should be doable with the early cfg building framework and the code
to determine number of iterations given that function has no irreducible
regions.
In fact at least internaly the notion of const and pure functions can be
probably decoupled into aliasing like info "reads this known set of
memories"/"writes this known set of memories" and the additional flags
"is finite" and "don't do anything nasty (like volatile asm or
whatever)"
We really worry about the finiteness (and nastyness) only when we are
going to remove the call (in DCE and CSE). Even RTL representation of
call has slot that can list memory references modified (the pure differs
from const in a way that it contains use of memory that can alias with
anything).
THis also reminds me that I used to have patch that makes us to CSE pure
functions on tree level so we can drop the libcall notes. I have to
look into what really happent with this thread.
>
> 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.
Concerning functions setting errno I guess one needs to prove that errno
is dead before removing the call that is tricky busynes.
Perhaps we can even have attribute that given function clobbers errno
so we can do the analysis.
We might have flag "sets errno but in const/pure way" so we can at least
CSE the functions... don't know here.
Honza
>
> Kenny