RFC: mark functions as const for possible optimizations

Nuno Lopes wrote:

My proposal is the following:
some functions when fed with constant arguments always return a constant
value, too. e.g.:
strlen('abcd') === 4.

wouldn't that be called "deterministic" and not "const"?

--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html

Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140

On Fri, 14 Sep 2007 18:01:13 +0100, in php.internals nlopess@php.net
("Nuno Lopes") wrote:

My proposal is the following:
some functions when fed with constant arguments always return a constant
value, too. e.g.:
strlen('abcd') === 4.

I like the general idea.

Would there be some caveats with stuff like this if it is possible to
change the charset at runtime?

I guess it is important to be aware of whether a function is affected
by different settings (and if these settings can be changed at
runtime) to conclude if a function really is deterministic at this
level.

--

• Peter Brodersen

From: "Nuno Lopes" nlopess@php.net
To: "PHPdev" internals@lists.php.net
Cc: stas@zend.com; andi@php.net; dmitry@php.net

My proposal is the following:
some functions when fed with constant arguments always return a constant
value, too. e.g.:
strlen('abcd') === 4.

This means that an optimizer can and should do this transformation. (and
others like: $a='abcd'; strlen($a); -> 4). I think Ilia created a list of
such functions in his optimizer. But I would like to have that list in the
core, so that everybody can benefit from it.
Basically the only thing needed to do is to change PHP_FE() to
PHP_CONST_FE() in the function entry tables.

I had a quick question about this. When would strlen('abcd') be execuated?
Say I had the code:

$a = false; // This set by external input
if ( $a )
$b = strlen('abcd');

Would the optimizer work out the length before the program starts to run? Or
would the optimizer wait until it knows the strlen is going to be called
then convert it to the constant 4?

I could see the optimizer "constifying" many function calls which will never
get called.

thanks
Andrew

Hi,

Just a thought, now dl() has been deprecated and disabled in SAPIs (except
CLI,CGI,embed), would that mean extension_loaded() would become a
optimizable function?

So something like

include extension_loaded('gmp') ? 'GMPFoo.php' : 'PHPFoo.php';

Would be optimized to be more APC friendly?

Jared

-----Original Message-----
From: Nuno Lopes [mailto:nlopess@php.net]
Sent: 14 September 2007 18:01
To: PHPdev
Cc: stas@zend.com; andi@php.net; dmitry@php.net
Subject: [PHP-DEV] RFC: mark functions as const for possible
optimizations

Hi,

Following my last post on bytecode optimization
(http://news.php.net/php.internals/32113), I would like to
discuss a few more things.
The patch in that e-mail allowed the engine itself to do
transformations like, e.g.:
$a = 12345+1-0; --> $a = 121;

However the patch is now a bit dead because Stas would like
to have more advanced things that I didn't have time yet to
look at (because the proposal introduces several difficult
ambiguities in the grammar).

So, let's move on for now :P

My proposal is the following:
some functions when fed with constant arguments always return
a constant value, too. e.g.:
strlen('abcd') === 4.

This means that an optimizer can and should do this
transformation. (and others like: $a='abcd'; strlen($a); ->
4). I think Ilia created a list of such functions in his
optimizer. But I would like to have that list in the core, so
that everybody can benefit from it.
Basically the only thing needed to do is to change PHP_FE() to
PHP_CONST_FE() in the function entry tables.

The patch:
http://web.ist.utl.pt/nuno.lopes/zend_const_function_entry.txt
(includes a few function entries changed as an example)

Nuno

P.S.: the university semester has already started, so don't
worry with the
e-mail traffic I'm generating because it'll end pretty soon
(until the next
vacations :P)