Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86565
Return-Path: <php_lists@realplain.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 47215 invoked from network); 10 Jun 2015 15:44:07 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Jun 2015 15:44:07 -0000
Authentication-Results: pb1.pair.com smtp.mail=php_lists@realplain.com; spf=permerror; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=php_lists@realplain.com; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain realplain.com from 216.33.127.80 cause and error)
X-PHP-List-Original-Sender: php_lists@realplain.com
X-Host-Fingerprint: 216.33.127.80 mta11.charter.net Solaris 10 1203
Received: from [216.33.127.80] ([216.33.127.80:59046] helo=mta11.charter.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 9D/56-15306-44B58755 for <internals@lists.php.net>; Wed, 10 Jun 2015 11:44:06 -0400
Received: from imp11 ([10.20.200.11]) by mta11.charter.net
          (InterMail vM.8.01.05.09 201-2260-151-124-20120717) with ESMTP
          id <20150610154401.YGLA5815.mta11.charter.net@imp11>;
          Wed, 10 Jun 2015 11:44:01 -0400
Received: from mtaout003.msg.strl.va.charter.net ([68.114.190.28])
	by imp11 with smtp.charter.net
	id efk11q00A0dCcRg05fk1cD; Wed, 10 Jun 2015 11:44:01 -0400
Received: from impout002 ([68.114.189.17])
          by mtaout003.msg.strl.va.charter.net
          (InterMail vM.9.00.015.01 201-2473-143-101) with ESMTP
          id <20150610154401.GNCZ7013.mtaout003.msg.strl.va.charter.net@impout002>;
          Wed, 10 Jun 2015 10:44:01 -0500
Received: from pc1 ([96.35.251.86])
	by impout002 with charter.net
	id efk11q0071sc0so01fk1Kz; Wed, 10 Jun 2015 10:44:01 -0500
X-Authority-Analysis: v=2.1 cv=eMidjRZ1 c=1 sm=1 tr=0
 a=Is5gsZaFXO8aPum+t7Tz+g==:117 a=Is5gsZaFXO8aPum+t7Tz+g==:17 a=hOpmn2quAAAA:8
 a=N659UExz7-8A:10 a=BCPeO_TGAAAA:8 a=67BIL_jfAAAA:8 a=MIzFoyp_v5vCZNFiItUA:9
 a=pILNOxqGKmIA:10
Message-ID: <2139882728E84052BB402C22B10BE768@pc1>
To: "Sara Golemon" <pollita@php.net>
Cc: "Dmitry Stogov" <dmitry@php.net>,
	"Stanislav Malyshev" <smalyshev@gmail.com>,
	"PHP internals" <internals@lists.php.net>
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 10:44:01 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Subject: Re: [PHP-DEV] Undefined variables undefined order
From: php_lists@realplain.com ("Matt Wilmas")

Hi Sara,

----- Original Message -----
From: "Sara Golemon"
Sent: Wednesday, June 10, 2015

> 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?
> Doesn't the compiler fold (<const-string> . <const-string>) already
> anyhow?  How would we wind up with CONCAT_CONST_CONST at runtime?
>
>> 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 the
> instructions in a way which satisfies the explicit order, but as an
> inline call.

I don't know...  Yeah, if op1 is coming from a "plain" variable, either 
something simple (like CONST?) or after function inlining.  e.g. Like 
"directly" accessible, then it should be able to be done the same.  (I don't 
know a lot about any of this though.)

I was thinking of when some sort of function call is involved (as far as 
unavoidable extra instructions).  If op1 is fetched after op2, it's 
optimized for passing to concat_function(), etc.  Doing stuff in reverse 
order will need fewer instructions than "human order," at least when 
function calls are needed for "stuff."

Hmm, maybe that's only for x86 with push'ed args, where each thing can keep 
push'ing whatever it needs (eax) for the final (outer) function...  x86_64 
is I guess still going to need to store stuff "out of the way" for the next 
(inner) call, before moving it back to the necessary registers for the final 
function!  If that's true, maybe x86_64 doesn't need more instructions.

I think I've confused myself more trying to picture what's happening. :-O

> -Sara

- Matt