This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: pure/const function attribute and memoization
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Richard Biener <richard dot guenther at gmail dot com>, gcc <gcc at gcc dot gnu dot org>
- Date: Mon, 20 May 2013 14:39:28 +0200
- Subject: Re: pure/const function attribute and memoization
- References: <51933E30 dot 1040900 at redhat dot com> <CAFiYyc2=ZBhtbn4JLaaD0xcpvJ5dbN2os6YAX=9xHs0OO_7Hiw at mail dot gmail dot com> <5193516B dot 3040503 at redhat dot com> <20130518200243 dot GB20308 at atrey dot karlin dot mff dot cuni dot cz> <5197E311 dot 2020204 at redhat dot com>
>
> <http://sourceware.org/ml/libc-alpha/2013-05/msg00389.html>
>
> The function is in glibc's math/atest-exp2.c file.
I see, I was curious what made LLVM developers to implement the feature about making
memory writes unreachable. While I see wild interpretation of the documentation
allows it, I would not anticipate much benefits.
It is easy to add a warning (we analyze the function for autodetecting the attribute
and it is easy to warn when the properties are not matched).
With lowlevel stuff, like GLIBC, it is IMO perfectly sane to make memoizing function
const/pure when knowing it is never going to be called from same unit.
I.e. to arrange headers to make the function not const/pure when compiling the
unit containing it and const/pure for the external interface. The memoization
is completelly hidden from the compiler when linking application with GLIBC.
>
> >BTW we deduce all loops to be finite within const/pure functions that is also
> >bit crazy effect of the attribute.
>
> Uhm, okay.
>
> >The memoization you mention is IMO not really safe even with current GCC. With
> >bit of trickery one can convince GCC to early inline the memoizing const
> >function in some cases and not in others. Optimizers will then expect your
> >memoizing cache to not change across the non-inlined calls that may lead to
> >wrong code.
>
> Oh.
>
> >At the moment I can not think of anything that would break if you had pure/const
> >function modifying global memory and restoring it before returning.
>
> Well, with a bit of cheating, that's actually easy:
>
> int f1(void) __attribute__((const));
> void f2(int);
> void lock(void);
> void unlock(void);
>
> void
> g()
> {
> for (int i = 0; i < 10; ++i) {
> lock();
> f2(f1());
> unlock();
> }
> }
Yeah, that is cheating though ;) Either your program should be non-threaded
or you pure/const function should be thread safe ;)
Honza