Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86569
Return-Path: <dmitry@zend.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 58457 invoked from network); 10 Jun 2015 17:57:13 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Jun 2015 17:57:13 -0000
Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.216.54 as permitted sender)
X-PHP-List-Original-Sender: dmitry@zend.com
X-Host-Fingerprint: 209.85.216.54 mail-vn0-f54.google.com  
Received: from [209.85.216.54] ([209.85.216.54:41587] helo=mail-vn0-f54.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 43/41-51179-67A78755 for <internals@lists.php.net>; Wed, 10 Jun 2015 13:57:12 -0400
Received: by vnbg190 with SMTP id g190so9413304vnb.8
        for <internals@lists.php.net>; Wed, 10 Jun 2015 10:57:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:cc:content-type;
        bh=A7ccu5dT5nk0jNJXu5IyzFE6ZLLyxbAgehreU+cbrts=;
        b=Lqv318usOWMkmOZ1hVE7L9f3S+T8JcGysZAJUjU3qP1w6HcwpzLlK7H7qxu7nRiKci
         EueWXVZiHr0YfOEiCW5wKB0L8d+mVbNOJht/ROmRaa82cMIwVr6CQxODwFBtLPJ6b/kb
         1cpWx0INRyDQ73TSkgfZoeCTiHQHLw33xKYI2DiMD5ixSpjzrAY1m4Jy0DBlksTj6wdj
         4dRI2eehbbruJkCuiIKZK7oflewCNWQI4ziYPwKsRhILXYQtwNuJRnBxfAPdReUr37ri
         94vmQS9hYv5FPdURAAPhBj+Ic2IpyYia+fEngxcc3Y/zAcHxW3JJVNNf/mZ2xtFEcRil
         GNnA==
X-Gm-Message-State: ALoCoQkaO/8sfZjpi/ABHnh94wSvIshvyVKPW1M1S8s4NrdKyQ0YFAEOph5z9flLj0Jjg4yJTp8eEQQzdscuBmaIu5zL66G8fNxAIGnfLcV/dgJTwv+WmU5QZVm/4tEEny67Noo+8fh8nuAiN+2FklOmE4VI1pz9RDmtgkNuLSqlxEEX0/VTiks=
MIME-Version: 1.0
X-Received: by 10.52.3.42 with SMTP id 10mr8582389vdz.10.1433959027571; Wed,
 10 Jun 2015 10:57:07 -0700 (PDT)
Received: by 10.31.10.201 with HTTP; Wed, 10 Jun 2015 10:57:07 -0700 (PDT)
In-Reply-To: <CAESVnVpBKS_0FMr-hXMWUsXURb=NbrfYXGLGVnnPH6y+byR24g@mail.gmail.com>
References: <CAESVnVr6oyAOCjWRWp7MGio_JNuUryPm=HKeY=fDgKRBcMXJ=Q@mail.gmail.com>
	<55513AA4.7010706@gmail.com>
	<579127CDC1B54040BEEFD4564A6F78B7@pc1>
	<CAESVnVpDXmLB-Gd_9HTyrdcnuS8g27Gezwgodb1CVLCVo0u2tg@mail.gmail.com>
	<1FAF88D0E2DE433FA299B4FAF7120880@pc1>
	<CAESVnVpBKS_0FMr-hXMWUsXURb=NbrfYXGLGVnnPH6y+byR24g@mail.gmail.com>
Date: Wed, 10 Jun 2015 20:57:07 +0300
Message-ID: <CA+9eiLt1qv8cBDd-smW-fTUS9q0Uv+gkZROO-WkkY1OfBeiahg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Matt Wilmas <php_lists@realplain.com>, Dmitry Stogov <dmitry@php.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=485b397dd613761b2205182d9acc
Subject: Re: [PHP-DEV] Undefined variables undefined order
From: dmitry@zend.com (Dmitry Stogov)

--485b397dd613761b2205182d9acc
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 10, 2015 at 5:42 PM, Sara Golemon <pollita@php.net> wrote:

> On Tue, Jun 9, 2015 at 6:05 AM, Matt Wilmas <php_lists@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
>

--485b397dd613761b2205182d9acc--