Hi Dmitry, all,
I was going to send this patch as a companion one to go with the
compile-time constant substitution change (Nuno sent a message about this
[1] last Sep. with a patch [2]), BUT I also realized that some different,
inconsistent behavior is possible because of that change.
First, the folding optimization part, which I don't know if you'll want to
use (though it seems pretty simple/safe to apply at any time), does the same
thing as Nuno's patch, but with a different implementation. This is even
more of an optimization when combined with constant substitution, for ORing
function flags, etc.
At the time, one of the objections (?) was that it didn't allow the same
constant expressions to initialize static variables and class
members/constants. (Though I don't see much relation: hidden, internal
optimization vs. actual syntax change/enhancement.) So I also added support
for arithmetic, bitwise, and concatenation operators (not logical or
comparison) in that context. Anyway, should be fairly simple to
understand... :-)
Now, the different, inconsistent behavior that's possible after the constant
substitution change. This code, for example:
function foo() {
static $a = -PHP_INT_MAX;
}
Would have previously given "Unsupported operand types". Now it can work
because the value of PHP_INT_MAX
may be substituted first. Fine, good;
except that it won't be substituted if it's in a namespace or
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is set, and then the error occurs.
I thought the best solution was to disallow constants in a "static_scalar"
expression (e.g. only literals). This shouldn't break anything unless
someone was using - or + signs on TRUE/FALSE/NULL. :-O That will cause a
parse error with my changes. Also:
function foo() {
static $a = -'abc'; // 0
static $b = +'abc'; // abc
$c = +'abc'; // 0
}
So I made the static_scalar unary + operator "do something" and behave like
the regular one. Again, shouldn't break anything unless someone was
applying + to literal strings or arrays!
Full patch with constant folding, etc.
http://realplain.com/php/const_folding.diff
http://realplain.com/php/const_folding_5_3.diff
-OR-, basic patch only containing the fix for signed static scalars, and
only an optimization to save the opcode for unary - and + applied to a
constant value (e.g. negative numbers, primarily):
http://realplain.com/php/signed_expr_tweaks.diff
http://realplain.com/php/signed_expr_tweaks_5_3.diff
Thoughts...? Thanks,
Matt
[1] http://marc.info/?l=php-internals&m=118925033731019&w=2
[2] http://web.ist.utl.pt/nuno.lopes/zend_constant_folding.txt
Hi Matt,
does the following code work with your patch?
<?php
function foo() {
static $a = A + B;
var_dump($a);
}
const A = 1;
const B = 2;
foo();
?>
It would be hard to explain why some of constant expression work, but
others don't.
Anyway, it's too late for this patches.
5.3 is going to be frozen.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry, all,
I was going to send this patch as a companion one to go with the
compile-time constant substitution change (Nuno sent a message about this
[1] last Sep. with a patch [2]), BUT I also realized that some different,
inconsistent behavior is possible because of that change.First, the folding optimization part, which I don't know if you'll want to
use (though it seems pretty simple/safe to apply at any time), does the same
thing as Nuno's patch, but with a different implementation. This is even
more of an optimization when combined with constant substitution, for ORing
function flags, etc.At the time, one of the objections (?) was that it didn't allow the same
constant expressions to initialize static variables and class
members/constants. (Though I don't see much relation: hidden, internal
optimization vs. actual syntax change/enhancement.) So I also added support
for arithmetic, bitwise, and concatenation operators (not logical or
comparison) in that context. Anyway, should be fairly simple to
understand... :-)Now, the different, inconsistent behavior that's possible after the constant
substitution change. This code, for example:function foo() {
static $a = -PHP_INT_MAX;
}Would have previously given "Unsupported operand types". Now it can work
because the value ofPHP_INT_MAX
may be substituted first. Fine, good;
except that it won't be substituted if it's in a namespace or
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is set, and then the error occurs.I thought the best solution was to disallow constants in a "static_scalar"
expression (e.g. only literals). This shouldn't break anything unless
someone was using - or + signs on TRUE/FALSE/NULL. :-O That will cause a
parse error with my changes. Also:function foo() {
static $a = -'abc'; // 0
static $b = +'abc'; // abc
$c = +'abc'; // 0
}So I made the static_scalar unary + operator "do something" and behave like
the regular one. Again, shouldn't break anything unless someone was
applying + to literal strings or arrays!Full patch with constant folding, etc.
http://realplain.com/php/const_folding.diff
http://realplain.com/php/const_folding_5_3.diff-OR-, basic patch only containing the fix for signed static scalars, and
only an optimization to save the opcode for unary - and + applied to a
constant value (e.g. negative numbers, primarily):
http://realplain.com/php/signed_expr_tweaks.diff
http://realplain.com/php/signed_expr_tweaks_5_3.diffThoughts...? Thanks,
Matt[1] http://marc.info/?l=php-internals&m=118925033731019&w=2
[2] http://web.ist.utl.pt/nuno.lopes/zend_constant_folding.txt
Hi Dmitry,
----- Original Message -----
From: "Dmitry Stogov"
Sent: Wednesday, July 30, 2008
Hi Matt,
does the following code work with your patch?
<?php
function foo() {
static $a = A + B;
var_dump($a);
}
const A = 1;
const B = 2;
foo();
?>It would be hard to explain why some of constant expression work, but
others don't.
No, it doesn't. That would of course require additional changes (I don't
know how to do that, didn't even look into it), and was also mentioned with
Nuno's patch. I just included the part I did for something "closer" to what
was talked about last time. The only explanation I know of would be that it
only works with literals, not named constants. But yes, it's hard to
understand. :-)
But anyway, it doesn't really matter to me about that, the main point (like
Nuno's) was the the folding of constant expressions in the other areas
(especially negative numbers). And like I said, it's more useful after
constant substitution with function flags being ORed and things like that...
But that could always be applied at a later date/version since it doesn't
break compatibility, right?
Anyway, it's too late for this patches.
5.3 is going to be frozen.
Well, what about the behavior change I mentioned? Something should be done
about that, I'm sure. That's what the second small patch
("signed_expr_tweaks") was for.
Actually, I wrote the above right after getting your message, but didn't
send it then, because I had only been thinking about the parser, and thought
of a more proper fix in zend_compile.c for the behavior difference (and
something else). I will send the fix shortly in a reply to the previous
thread about constant substitution... :-)
Thanks. Dmitry.
Thanks,
Matt
Matt Wilmas wrote:
Hi Dmitry, all,
I was going to send this patch as a companion one to go with the
compile-time constant substitution change (Nuno sent a message about
this
[1] last Sep. with a patch [2]), BUT I also realized that some
different,
inconsistent behavior is possible because of that change.First, the folding optimization part, which I don't know if you'll want
to
use (though it seems pretty simple/safe to apply at any time), does the
same
thing as Nuno's patch, but with a different implementation. This is
even
more of an optimization when combined with constant substitution, for
ORing
function flags, etc.At the time, one of the objections (?) was that it didn't allow the same
constant expressions to initialize static variables and class
members/constants. (Though I don't see much relation: hidden, internal
optimization vs. actual syntax change/enhancement.) So I also added
support
for arithmetic, bitwise, and concatenation operators (not logical or
comparison) in that context. Anyway, should be fairly simple to
understand... :-)Now, the different, inconsistent behavior that's possible after the
constant
substitution change. This code, for example:function foo() {
static $a = -PHP_INT_MAX;
}Would have previously given "Unsupported operand types". Now it can
work
because the value ofPHP_INT_MAX
may be substituted first. Fine, good;
except that it won't be substituted if it's in a namespace or
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is set, and then the error occurs.I thought the best solution was to disallow constants in a
"static_scalar"
expression (e.g. only literals). This shouldn't break anything unless
someone was using - or + signs on TRUE/FALSE/NULL. :-O That will cause
a
parse error with my changes. Also:function foo() {
static $a = -'abc'; // 0
static $b = +'abc'; // abc
$c = +'abc'; // 0
}So I made the static_scalar unary + operator "do something" and behave
like
the regular one. Again, shouldn't break anything unless someone was
applying + to literal strings or arrays!Full patch with constant folding, etc.
http://realplain.com/php/const_folding.diff
http://realplain.com/php/const_folding_5_3.diff-OR-, basic patch only containing the fix for signed static scalars, and
only an optimization to save the opcode for unary - and + applied to a
constant value (e.g. negative numbers, primarily):
http://realplain.com/php/signed_expr_tweaks.diff
http://realplain.com/php/signed_expr_tweaks_5_3.diffThoughts...? Thanks,
Matt[1] http://marc.info/?l=php-internals&m=118925033731019&w=2
[2] http://web.ist.utl.pt/nuno.lopes/zend_constant_folding.txt
Hi Matt,
For now I would like to disable "-CONST" constant expression which
started to work after your patch.
Later we are able to implement the complete constant expressions support.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
----- Original Message -----
From: "Dmitry Stogov"
Sent: Wednesday, July 30, 2008Hi Matt,
does the following code work with your patch?
<?php
function foo() {
static $a = A + B;
var_dump($a);
}
const A = 1;
const B = 2;
foo();
?>It would be hard to explain why some of constant expression work, but
others don't.No, it doesn't. That would of course require additional changes (I don't
know how to do that, didn't even look into it), and was also mentioned with
Nuno's patch. I just included the part I did for something "closer" to what
was talked about last time. The only explanation I know of would be that it
only works with literals, not named constants. But yes, it's hard to
understand. :-)But anyway, it doesn't really matter to me about that, the main point (like
Nuno's) was the the folding of constant expressions in the other areas
(especially negative numbers). And like I said, it's more useful after
constant substitution with function flags being ORed and things like that...
But that could always be applied at a later date/version since it doesn't
break compatibility, right?Anyway, it's too late for this patches.
5.3 is going to be frozen.Well, what about the behavior change I mentioned? Something should be done
about that, I'm sure. That's what the second small patch
("signed_expr_tweaks") was for.Actually, I wrote the above right after getting your message, but didn't
send it then, because I had only been thinking about the parser, and thought
of a more proper fix in zend_compile.c for the behavior difference (and
something else). I will send the fix shortly in a reply to the previous
thread about constant substitution... :-)Thanks. Dmitry.
Thanks,
MattMatt Wilmas wrote:
Hi Dmitry, all,
I was going to send this patch as a companion one to go with the
compile-time constant substitution change (Nuno sent a message about
this
[1] last Sep. with a patch [2]), BUT I also realized that some
different,
inconsistent behavior is possible because of that change.First, the folding optimization part, which I don't know if you'll want
to
use (though it seems pretty simple/safe to apply at any time), does the
same
thing as Nuno's patch, but with a different implementation. This is
even
more of an optimization when combined with constant substitution, for
ORing
function flags, etc.At the time, one of the objections (?) was that it didn't allow the same
constant expressions to initialize static variables and class
members/constants. (Though I don't see much relation: hidden, internal
optimization vs. actual syntax change/enhancement.) So I also added
support
for arithmetic, bitwise, and concatenation operators (not logical or
comparison) in that context. Anyway, should be fairly simple to
understand... :-)Now, the different, inconsistent behavior that's possible after the
constant
substitution change. This code, for example:function foo() {
static $a = -PHP_INT_MAX;
}Would have previously given "Unsupported operand types". Now it can
work
because the value ofPHP_INT_MAX
may be substituted first. Fine, good;
except that it won't be substituted if it's in a namespace or
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is set, and then the error occurs.I thought the best solution was to disallow constants in a
"static_scalar"
expression (e.g. only literals). This shouldn't break anything unless
someone was using - or + signs on TRUE/FALSE/NULL. :-O That will cause
a
parse error with my changes. Also:function foo() {
static $a = -'abc'; // 0
static $b = +'abc'; // abc
$c = +'abc'; // 0
}So I made the static_scalar unary + operator "do something" and behave
like
the regular one. Again, shouldn't break anything unless someone was
applying + to literal strings or arrays!Full patch with constant folding, etc.
http://realplain.com/php/const_folding.diff
http://realplain.com/php/const_folding_5_3.diff-OR-, basic patch only containing the fix for signed static scalars, and
only an optimization to save the opcode for unary - and + applied to a
constant value (e.g. negative numbers, primarily):
http://realplain.com/php/signed_expr_tweaks.diff
http://realplain.com/php/signed_expr_tweaks_5_3.diffThoughts...? Thanks,
Matt[1] http://marc.info/?l=php-internals&m=118925033731019&w=2
[2] http://web.ist.utl.pt/nuno.lopes/zend_constant_folding.txt
Hi Dmitry,
----- Original Message -----
From: "Dmitry Stogov"
Sent: Thursday, July 31, 2008
Hi Matt,
For now I would like to disable "-CONST" constant expression which
started to work after your patch.
Yes, that's what my new fix will do -- it's coming in just a minute, and it
also corrects part of the constant substitution that isn't working right
now. Just a sec. :-)
Later we are able to implement the complete constant expressions support.
Thanks. Dmitry.
Thanks,
Matt
Hi again Dmitry,
----- Original Message -----
From: "Dmitry Stogov"
Sent: Thursday, July 31, 2008
Hi Matt,
For now I would like to disable "-CONST" constant expression which
started to work after your patch.Later we are able to implement the complete constant expressions support.
One more updated thing to ask about. :-) From the last reply, I wasn't sure
if constant folding in zend_do_[binary|unary]_op() could be added (for
negative numbers, ORing function flags that were substituted, ~0, 1024 *
1024, etc.) or it was desired to wait for "complete constant expressions
support" (in static_scalar context), though I don't see any relation between
that, which is an actual language change, and this easy optimization that's
only internal (and more useful now with constant substitution).
So I updated the patch, which is the same code as before, but without trying
to add partial expression support to static_scalar. Seems pretty
simple/safe, with basically just the if () { } block added in
zend_do_[binary|unary]_op(). :-) The rest updates the unary_op_type typedef
(was missing TSRMLS_DC), adds binary_op_type, and updates get_binary_op
(half the patch!). The couple changes in the parser, which CAN be ignored
if desired, are mostly a cleanup, but '+' static_scalar now actually "does
something" like the unary + operator in regular contexts. As I showed
before, it makes the following consistent:
function foo() {
static $a = -'abc'; // 0
static $b = +'abc'; // abc
$c = +'abc'; // 0
}
http://realplain.com/php/const_folding.diff
http://realplain.com/php/const_folding_5_3.diff
Well, I don't know if it can be tossed in quickly at this time, but there ya
go since I think it's pretty basic! ;^)
Thanks. Dmitry.
Thanks,
Matt
Hi Matt,
Sorry, I just don't have time to look into it in last minute.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi again Dmitry,
----- Original Message -----
From: "Dmitry Stogov"
Sent: Thursday, July 31, 2008Hi Matt,
For now I would like to disable "-CONST" constant expression which
started to work after your patch.Later we are able to implement the complete constant expressions support.
One more updated thing to ask about. :-) From the last reply, I wasn't sure
if constant folding in zend_do_[binary|unary]_op() could be added (for
negative numbers, ORing function flags that were substituted, ~0, 1024 *
1024, etc.) or it was desired to wait for "complete constant expressions
support" (in static_scalar context), though I don't see any relation between
that, which is an actual language change, and this easy optimization that's
only internal (and more useful now with constant substitution).So I updated the patch, which is the same code as before, but without trying
to add partial expression support to static_scalar. Seems pretty
simple/safe, with basically just the if () { } block added in
zend_do_[binary|unary]_op(). :-) The rest updates the unary_op_type typedef
(was missing TSRMLS_DC), adds binary_op_type, and updates get_binary_op
(half the patch!). The couple changes in the parser, which CAN be ignored
if desired, are mostly a cleanup, but '+' static_scalar now actually "does
something" like the unary + operator in regular contexts. As I showed
before, it makes the following consistent:function foo() {
static $a = -'abc'; // 0
static $b = +'abc'; // abc
$c = +'abc'; // 0
}http://realplain.com/php/const_folding.diff
http://realplain.com/php/const_folding_5_3.diffWell, I don't know if it can be tossed in quickly at this time, but there ya
go since I think it's pretty basic! ;^)Thanks. Dmitry.
Thanks,
Matt
Hi!
static $a = -'abc'; // 0 static $b = +'abc'; // abc $c = +'abc'; // 0
}
We could get into trouble here. Imagine:
static $a = -'12.8';
This should be -12.8, but what if locale changes and . is no longer
decimal separator? Moreover, what if locale changes between compile and
runtime? We get entirely different code now.
Well, I don't know if it can be tossed in quickly at this time, but there ya
go since I think it's pretty basic! ;^)
I think it's not the feature that can be "tossed in quickly" - it can
have some obscure side effects, as I described in my later emails.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Stas,
We discussed this patch with Matt, and I allowed this change.
So it probably my fault (I missed run-time locale change possibility).
I don't think it is a really big issue, but it really may change
behavior of some scripts.
I think we should revert this patch, before we get complete solution for
compile-time expression evaluation (not in 5.3 of course).
Thanks. Dmitry.
Stanislav Malyshev wrote:
Hi!
static $a = -'abc'; // 0 static $b = +'abc'; // abc $c = +'abc'; // 0
}
We could get into trouble here. Imagine:
static $a = -'12.8';This should be -12.8, but what if locale changes and . is no longer
decimal separator? Moreover, what if locale changes between compile and
runtime? We get entirely different code now.Well, I don't know if it can be tossed in quickly at this time, but
there ya
go since I think it's pretty basic! ;^)I think it's not the feature that can be "tossed in quickly" - it can
have some obscure side effects, as I described in my later emails.
Hi Stas, Dmitry,
I forgot to reply to Stas' message yesterday, sorry... But, there is no
change in behavior here either as far as I know. For the code Stas quoted,
with static vars (if that's what was being referred to), there's definitely
not been a change (though its parser code was tweaked a bit), and there has
never been a locale issue, and the operand negation happens at compile-time
(as always).
The reason there should also be no change doing +/- at compile time now (out
of static_scalar context) with constant values is because locale does not
affect string to number conversion -- only '.' works as a decimal point in
is_numeric_string() (maybe zend_strtod() too; didn't look), so there's no
way the conversion could be different during runtime. :-)
Now for going the other way, double to string, locale is honered, I believe?
In that case, Dmitry, that would be another issue trying to do the full
folding (with ZEND_CONCAT), with something like
$a = 'abc ' . 1.23;
So good thing it's left out for now! (Hmm, don't [some] optimizers do this
folding? Maybe they haven't considered the locale issue...)
But anyway, I don't think there are any worries about the current code and
what has been done.
Thanks,
Matt
----- Original Message -----
From: "Dmitry Stogov"
Sent: Sunday, August 31, 2008
Hi Stas,
We discussed this patch with Matt, and I allowed this change.
So it probably my fault (I missed run-time locale change possibility).
I don't think it is a really big issue, but it really may change
behavior of some scripts.
I think we should revert this patch, before we get complete solution for
compile-time expression evaluation (not in 5.3 of course).Thanks. Dmitry.
Stanislav Malyshev wrote:
Hi!
static $a = -'abc'; // 0 static $b = +'abc'; // abc $c = +'abc'; // 0
}
We could get into trouble here. Imagine:
static $a = -'12.8';This should be -12.8, but what if locale changes and . is no longer
decimal separator? Moreover, what if locale changes between compile and
runtime? We get entirely different code now.Well, I don't know if it can be tossed in quickly at this time, but
there ya
go since I think it's pretty basic! ;^)I think it's not the feature that can be "tossed in quickly" - it can
have some obscure side effects, as I described in my later emails.
Hi!
I forgot to reply to Stas' message yesterday, sorry... But, there is no
change in behavior here either as far as I know. For the code Stas quoted,
with static vars (if that's what was being referred to), there's definitely
not been a change (though its parser code was tweaked a bit), and there has
never been a locale issue, and the operand negation happens at compile-time
(as always).
Yes, it seems like you are right - for such cases it happens in compile
time in any case.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com