On Wed, Jun 10, 2015 at 5:42 PM, Sara Golemon <poll...@php.net> wrote:
> On Tue, Jun 9, 2015 at 6:05 AM, Matt Wilmas <php_li...@realplain.com> > wrote: > > Hah, looks like this just changed last week after barely 3 weeks. :-P I > > didn't verify, just noticed the code change: > > > http://git.php.net/?p=php-src.git;a=commitdiff;h=c09698753e7d1d95299dca54c8ca888c885fd45b > > > Dmitry, what's the reasoning behind this diff in the first place? > Inlining of fast path and omitting check for Z_TYPE_P() for IS_CONST operands. > Doesn't the compiler fold (<const-string> . <const-string>) already > anyhow? How would we wind up with CONCAT_CONST_CONST at runtime? > It's probably makes sense to try to do this for most binary/unary opcodes. I'll think about it. > > > Now CONCAT is consistent, but not others. Which places need changing > > anyway? Just binary ops in VM? > > > > A couple/few extra instructions are unavoidable, I guess on any > > architecture, for the intermediate save of op1, but can anyone show that > it > > makes ANY measurable difference (other than instruction count)? > > > I'm 90% certain that fixing the ordering (by saving to a temp var) > doesn't *actually* result in extra instructions. GCC's optimizer is > pretty clever. It'll notice you're only writing to the temp var once, > and reading from it once (immediately), so it'll end up organizing theIt > won't take more than a half an hour. > > instructions in a way which satisfies the explicit order, but as an > inline call. > I also think, this won't affect performance, and I may check this, creating a patch for all binary operators. Anyway, I don't object against this change, but I think, the order of operands evaluation must not be defined (by PHP specification). Thanks. Dmitry. > > -Sara >
