Re: [patch] 2 patches for PR tree-optimization/34648

[Laurent GUERBY <laurent at guerby dot net>]

On Fri, 2008-01-18 at 11:32 -0500, Daniel Berlin wrote:
> On Jan 18, 2008 9:23 AM, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> > > > Are you
> > > > saying that it's invalid for a programmer to declare a function pure if it
> > > > uses memoization?
> > >
> > > Yes.  See http://thread.gmane.org/gmane.comp.gcc.patches/68255 (you
> > > disagreed in that thread, too).
> >
> > Interesting.  As Laurent Guerby points out in that thread, Ada permits
> > Pure functions to be memoized.

In the Ada 2005 Annotated RM there is a comment about this:

<<
10.2.1 Elaboration Control
[...]
                         Implementation Permissions

18/2  {AI95-00366-01} If a library unit is declared pure, then the
implementation is permitted to omit a call on a library-level subprogram of
the library unit if the results are not needed after the call. In addition,
the implementation may omit a call on such a subprogram and simply reuse the
results produced by an earlier call on the same subprogram, provided that none
of the parameters nor any object accessible via access values from the
parameters are of a limited type, and the addresses and values of all
by-reference actual parameters, the values of all by-copy-in actual
parameters, and the values of all objects accessible via access values from
the parameters, are the same as they were at the earlier call. [This
permission applies even if the subprogram produces other side effects when
called.]

    18.a/2 Discussion: {AI95-00366-01} A declared-pure library_item has no
          variable state. Hence, a call on one of its (nonnested) subprograms
          cannot normally have side effects. The only possible side effects
          from such a call would be through machine code insertions, imported
          subprograms,unchecked conversion to an access type declared within
          the subprogram, and similar features. The compiler may omit a call
          to such a subprogram even if such side effects exist, so the writer
          of such a subprogram has to keep this in mind.
>>

> The disconnect between various ideas of const/pure (in languages,
> math, etc) is one of the reasons i've pushed for us to simply have a
> set of attributes that make up pure/const (IE no_side_effects,
> no_memory_reads, etc) and have pure/const in each language simply set
> the right ones.
> Right now we try to carry some idea of pure/const into the middle-end
> (through DECL_PURE/etc), and nobody is ever really truly sure what
> pure/const actually mean (we seem to have a thread every 5-6 months
> about it).  We should just transform it into a bitmask of separate
> attributes.

Matches what I said in 2004 :)

http://article.gmane.org/gmane.comp.gcc.devel/51843
<<
The semantics for Pure are not described as "no side effect", but as
permission to omit a call if it meets a precise list of conditions,
and nothing else.

Defined this way, it allows some optimizations and not others, and
in particular it prevents the compiler when it decides to emit a call
from assuming that nothing will change during the call which
is necessary if you want to do memoizing reliably : you can
just pragma Import a side-effect generating procedure and call it within
the Pure function code, and everything will work as expected.

Defined as "no side effect" (assuming this can be described properly)
it will allow other optimizations, and disallow memoizing altogether.

As a programmer I see that as two different semantics, both
useful and none to throw away IMHO that's why I was proposing
a new pragma for the second one (which should match the GNU C
extension).
>>

Laurent