Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86552 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25037 invoked from network); 10 Jun 2015 14:42:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jun 2015 14:42:35 -0000 Authentication-Results: pb1.pair.com header.from=php@golemon.com; sender-id=softfail Authentication-Results: pb1.pair.com smtp.mail=php@golemon.com; spf=softfail; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.217.172 as permitted sender) X-PHP-List-Original-Sender: php@golemon.com X-Host-Fingerprint: 209.85.217.172 mail-lb0-f172.google.com Received: from [209.85.217.172] ([209.85.217.172:34880] helo=mail-lb0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CA/81-15306-9DC48755 for ; Wed, 10 Jun 2015 10:42:34 -0400 Received: by lbbtu8 with SMTP id tu8so30175938lbb.2 for ; Wed, 10 Jun 2015 07:42:30 -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:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bgSwPjJyB8HtR76M8in6eT3p3WSb4U2MozUW2n17kwQ=; b=e3AKZi3lLjknst+9hMX6m0/+1fMuFfObM83F9NnCBB0Yhku1WPR9duSXahIxCu6rYT Zzq5JdGOmS2AQuJtSHyjTjnLNIfd4MX0GAnvHZeGbd+PVjyuNfyZCoRsph1t+JKH238f Lewp9liewva/1LjldlZXrbShv9pK9MvPXGNeEWjfbDR6Z34aaItAZjri7b1iATQErcwT 4Rgzws2MbyM3oCvhycghpKuWoblABWJnARxqaFJ6kGnvjqUpNuBG2OSpytOB1p+mFips FFlIZt+ayB73DQS3I7MxBiUpdnB/a2DZ4pWT/R4jmR1+91zERiifyOIceoF4lLQkjz4o ssNg== X-Gm-Message-State: ALoCoQlsJO4H8L2OfcGTeNhItsKnmHyYGxIWOX2qQlbKbvpMQ7O9sKdRAK1Gx6SrjVzNVycUWTwk MIME-Version: 1.0 X-Received: by 10.152.37.196 with SMTP id a4mr4468723lak.59.1433947350115; Wed, 10 Jun 2015 07:42:30 -0700 (PDT) Sender: php@golemon.com Received: by 10.112.11.134 with HTTP; Wed, 10 Jun 2015 07:42:30 -0700 (PDT) X-Originating-IP: [73.189.247.124] In-Reply-To: <1FAF88D0E2DE433FA299B4FAF7120880@pc1> References: <55513AA4.7010706@gmail.com> <579127CDC1B54040BEEFD4564A6F78B7@pc1> <1FAF88D0E2DE433FA299B4FAF7120880@pc1> Date: Wed, 10 Jun 2015 07:42:30 -0700 X-Google-Sender-Auth: 81AwuyeQNCQWpzBD1wY3cSXYe3I Message-ID: To: Matt Wilmas Cc: Dmitry Stogov , Stanislav Malyshev , PHP internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Undefined variables undefined order From: pollita@php.net (Sara Golemon) On Tue, Jun 9, 2015 at 6:05 AM, Matt Wilmas 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 ( . ) 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. -Sara