Re: [PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
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, 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
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
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, 2008
>
>> Hi Matt,
>>
>> does the following code work with your patch?
>>
>> > 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 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
[PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
Hi Dmitry,
- Original Message -
From: "Dmitry Stogov"
Sent: Wednesday, July 30, 2008
> Hi Matt,
>
> does the following code work with your patch?
>
> 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 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
> >
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
Hi Matt,
does the following code work with your patch?
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 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
