# RFC: mark functions as const for possible optimizations

- Thread: https://externals.io/message/32326
- Original archive: https://news-web.php.net/php.internals/32326
- Started by Nuno Lopes on 2007-09-14T17:01:13+00:00
- Messages: 10
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #32326 — Nuno Lopes — 2007-09-14T17:01:13+00:00

URL: https://externals.io/message/32326#32326

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 = 1*2*3*4*5+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)

---

## #32327 — Hartmut Holzgraefe — 2007-09-14T17:11:35+00:00

URL: https://externals.io/message/32326#32327 · In reply to: #32326

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

---

## #32328 — Nuno Lopes — 2007-09-14T18:42:20+00:00

URL: https://externals.io/message/32326#32328 · In reply to: #32327

> Nuno Lopes wrote:
> > […]
>
> wouldn't that be called "deterministic" and not "const"?

yeah, exactly. I was missing the correct wording. (btw, appart of being 
deterministic, the function shouldn't have any side-effect).
Nuno

---

## #32329 — Peter Brodersen — 2007-09-15T11:45:12+00:00

URL: https://externals.io/message/32326#32329 · In reply to: #32326

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

---

## #32348 — Nuno Lopes — 2007-09-16T19:02:19+00:00

URL: https://externals.io/message/32326#32348 · In reply to: #32329

> > […]
>
> 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.

uhm, damn, right. `strlen()` wasn't a good example.. my bad, sorry :S
Anyway, you got the idea :)

Nuno

---

## #32349 — johannes@php.net — 2007-09-16T23:05:23+00:00

URL: https://externals.io/message/32326#32349 · In reply to: #32348

Hi Nuno,


> > […]
> 
> uhm, damn, right. `strlen()` wasn't a good example.. my bad, sorry :S
> Anyway, you got the idea :)

Nothing wrong with strlen as far as I can tell:

- In PHP 5 we only have binary strings so `strlen()` works independent 
  from any charsets and encodings by just counting bytes.
- In PHP 6 we know - assuming the parameter is a constant string - the
  encoding at compile time, therefore it could be used.

The only edge-case I see is if somebody uses mbstring.func_overload and
overwrites `strlen()`

johannes

---

## #32357 — Nuno Lopes — 2007-09-17T11:10:20+00:00

URL: https://externals.io/message/32326#32357 · In reply to: #32349

> 
> > […]
>
> Nothing wrong with strlen as far as I can tell:
>
> - In PHP 5 we only have binary strings so `strlen()` works independent
>  from any charsets and encodings by just counting bytes.
> - In PHP 6 we know - assuming the parameter is a constant string - the
>  encoding at compile time, therefore it could be used.
>
> The only edge-case I see is if somebody uses mbstring.func_overload and
> overwrites `strlen()`


exactly. I was thinking in mbstring, too. As long as there is some run-time 
setting that can affect a function, we cannot replace its call blindly with 
its value. Then only a more intelligent optimizer can do inference on the 
code and figure out if it's safe or not to replace the function call.
My proposal was to mark functions susceptible of that "blind" replacement 
only.

Nuno

---

## #32358 — Andrew Brampton — 2007-09-17T12:21:41+00:00

URL: https://externals.io/message/32326#32358 · In reply to: #32326

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

---

## #32359 — Nuno Lopes — 2007-09-17T13:45:04+00:00

URL: https://externals.io/message/32326#32359 · In reply to: #32358

> 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?

That's not my problem.. My RFC is about making the information available, 
not writing the optimizer itself (at least for now). With a naive optimizer, 
 `strlen()` would be called, yes.

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

that's not a problem since you would use a cache..

Nuno

---

## #32444 — Jared Williams — 2007-09-25T11:01:48+00:00

URL: https://externals.io/message/32326#32444 · In reply to: #32326

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 = 1*2*3*4*5+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)