Constant expressions are not optimized under some conditions

[mvorisek]

Description

The following code:

https://3v4l.org/Btrh0/rfc#vgit.master_jit

Resulted in this output:

float(0.1064751148223877)
float(0.07117080688476562)
float(0.3041820526123047)

But I expected this output instead:

float(0.1064751148223877)
float(0.07117080688476562)
float(0.07117080688476562)

I expect array_keys to be optimized to const with const input. 2nd and 3rn time must be about the same.

I also expect in_array to be optimized to use hash based 0(1) lookup when the array is const.

PHP Version

any

Operating System

any

[nielsdos]

There are many things that could in theory be constant-evaluated at compile time. The question is whether those cases are common enough to justify special-casing a constant-evaluation path for them. Tbh, I'm not convinced a function like this is a bottleneck in real-world applications.

[mvorisek]

array_keys is pure function, for I would say every pure function can and should be evaluated only once* if the args are const

* at compile time or on the 1st use, at least with JIT

[Girgias]

That's not a bug, what you are asking for is an optimizer feature, and a quite complicated one on top.

[mvorisek]

@Girgias why is array_keys complicated to implement? It should be not hard, const. array is accepted, transformed and stored.

[nielsdos]

If it's so simple, why don't you try it yourself and see that it's more complicated than you think ;)

[mvorisek]

I am not familiar with all the php-src internals, that's why I opened this issue instead of proposing a PR directly. Maybe it is complicated, what are the challenges?

[Girgias]

@Girgias why is array_keys complicated to implement? It should be not hard, const. array is accepted, transformed and stored.

Do not evaluate the complexity of a feature when you have literally no idea what is involved in making this feature happen.
If it's so easy, why don't you do it? Why don't you generalize it to all internal pure functions, and why don't you generalize it to all known pure userland functions?

If you actually thought it was that easy, you would have gone and tried to create this feature yourself via a PR and realize the complexity. Asking other peoples to do it under the purview of you not knowing php-src internals shows a lack of wanting to learn and wasting maintainers time needing to reply to you.

I would urge you to reconsider your interactions with the project as you comment on PRs and act like a maintainer when you are clearly not, and you do not have the knowledge required (proven here by your questions and widely wrong assessments). Moreover, opening draft PRs to attempt to fix bugs just to put a review comment which basically summarizes to "how do I fix this bug", and outright ignoring review comments from actual maintainers because you disagree with them just to harass them afterwards to merge your PR has given you a notoriously bad reputation within the project.

You do provide useful contribution at times, and we appreciate it. However, more often than not, what you are doing is just noise and a waste of time for us to deal with when we could be doing something else. So think twice (or even thrice) before opening an issue, commenting a PR, or generally just interacting with the project.

[bwoebi]

@Girgias Thanks for putting it on point.

[mvorisek]

@Girgias at least before https://github.com/php/php-src/pull/7780/files#diff-8a2df74d9492ec07c0c953e243b3592538d3a46c9861bffd35dd6500300d8117L813 PR array_keys and array_key_exists functions were present as a functions supporting CTE. I would expect php to eval such functions only once if the args are const. This is why I opened this issue.

[KapitanOczywisty]

@Girgias at least before https://github.com/php/php-src/pull/7780/files#diff-8a2df74d9492ec07c0c953e243b3592538d3a46c9861bffd35dd6500300d8117L813 PR array_keys and array_key_exists functions were present as a functions supporting CTE.

PR changed only how CTE functions are defined, both array_keys and array_key_exists are still supported for CTE. Have you measured performance in version before that PR? Also I don't know if variable argument can be treated as constant.

[mvorisek]

Yes, I fully understand the PR. My expectation is the following - optimizer tracks what variables are const and if a function is marked as CTE and the parameters are const, function is evaluated at compile time *. With the repro code it is not the case. And I wonder why.

In the repro code I measured time with JIT enabled, and even JIT seems to evaluate functions marked as CTE multiple times, so I belive there is some problem.

[nielsdos]

A variable (CV) and a const are 2 different things.