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: Richard Biener <richard dot guenther at gmail dot com>, gcc <gcc at gcc dot gnu dot org>
- Date: Sat, 18 May 2013 22:02:43 +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>
> On 05/15/2013 11:01 AM, Richard Biener wrote:
> >Now - if there would ever be an architecture where special call-site preparation
> >is required for a callee to write to global memory then marking a function 'const'
> >when it does in fact write to global memory then GCC may choose to optimize
> >the call site to not do that call-site preparation. At least that
> >would be valid according to the current documentation.
>
> That's a good point.
>
> The more immediate concern is that the compiler could apply the
> const attribute to the function definition itself and deduct that
> code paths with global memory references are unreachable.
> Apparently, this is something that Clang does in some cases.
It is bit crazy idea though :) Do you have reference to the corresponding thread?
I wonder what would be motivations for this.
BTW we deduce all loops to be finite within const/pure functions that is also
bit crazy effect of the attribute.
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.
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.
Honza