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.
- From: Tom Tromey <tromey at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: "Novillo, Diego" <dnovillo at redhat dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, "Berlin, Daniel" <dberlin at dberlin dot org>
- Date: 11 Nov 2004 11:22:21 -0700
- Subject: Re: a question about const and pure functions.
- References: <41937497.7010501@naturalbridge.com><Pine.LNX.4.44.0411110627040.25993-100000@www.eyesopen.com>
- Reply-to: tromey at redhat dot com
>>>>> "Roger" == Roger Sayle <roger@eyesopen.com> writes:
Roger> A "const" call has no side-effects and its results depend
Roger> purely on the values of its arguments. This closely follows
Roger> the mathematical notion of a "function". A "pure" call has no
Roger> side-effects, but in addition to it's arguments may depend upon
Roger> the memory/global variables of the system.
In libgcj we have a function called _Jv_InitClass that is used to
initialize a class. It is a `void' function. The first call to it in
a given function, with a given class argument, cannot be eliminated,
but all subsequent calls can. I.e., this function is idempotent but
not pure or const, at least not by the above definitions.
This function has some other properties that can be exploited for
optimization though. Initializing a class causes all its concrete
superclasses to be initialized as well. This means that if we see a
call to _Jv_InitClass for a given class, we can also eliminate all
subsequent calls to _Jv_InitClass with arguments which are known to be
superclasses.
Right now we do some optimization in this area by introducing a local
variable for each class to track whether we've called _Jv_InitClass,
and we make calls to _Jv_InitClass conditional on the corresponding
local. This is ok, in that it works, but it doesn't handle the
superclass case, and it interacts poorly with inlining (after inlining
we need to merge these synthetic locals, but we don't).
So, what to do?
We could have a new "idempotent" attribute. This would not get the
superclass optimization but would solve the inlining problem.
Or we could somehow teach tree-ssa about the java type system... a
front-end specific pass? Or extend the local variable approach to do
merging after inlining and to also track all superclasses?
Tom