a question about const and pure functions.

[Roger Sayle]

On 11 Nov 2004, Tom Tromey wrote:
> We could have a new "idempotent" attribute.  This would not get the
> superclass optimization but would solve the inlining problem.

If the performance overhead of the multiple calls to _Jv_InitClass
is a significant problem, then a new idempotent attribute might not
be unreasonable.  idempotency is the kind of attribute that can be
determined by the types of analysis proposed by Kenneth, but one
possible issue is that apart from _Jv_InitClass, it may not occur
very frequently in practice, i.e. user-written code.  It could
conceivably help libmudflap though.

The other issue is that there are currently no passes or mechanisms
for eliminating idempotent functions in GCC.  Because _Jv_InitClass
doesn't return a value, it's unlike pure/const functions where
CSE/GCSE could be tweaked to take care of this automatically.


If the conclussion is that you need to add a new tree-ssa pass,
specifically for eliminating "idempotent" functions, and this
pass only pays for itself on Java, it might be worth biting the
bullet, and enable front-ends to specify a langhook, or register
additional passes with the pass manager, and implement a special
purpose _Jv_InitClass optimization pass, that could simultaneously
handle _Jv_InitClass *and* implement the type hierarchy optimization.


Sorry if your question was rhetorical.  I've really no idea whether
idempotency is a significant source of optimization opportunities,
for example if any of the functions in SPEC, GCC or glibc could be
marked as idempotent?  Anyone?

Roger
--