Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93689
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CY1PR0201MB178644D71E69F51FD61E12E4BF470@CY1PR0201MB1786.namprd02.prod.outlook.com>
References: <CY1PR0201MB1786C24A2569B71BB6C716FBBF470@CY1PR0201MB1786.namprd02.prod.outlook.com>
	<CAL=_i_npftaNQ=vi2g8crrR57smMsbCMN08nnQteeHkPHc_XAA@mail.gmail.com>
	<CY1PR0201MB178644D71E69F51FD61E12E4BF470@CY1PR0201MB1786.namprd02.prod.outlook.com>
Date: Wed, 1 Jun 2016 21:01:52 +0200
Message-ID: <CAF+90c8rEE72+YUP-FxQEFfW0NYze-OYSP8PufqjFZf_g27wWQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Joe Watkins <pthreads@pthreads.org>, PHP internals <internals@lists.php.net>, 
	Nikita Popov <nikic@php.net>
Content-Type: multipart/alternative; boundary=001a114897a059270a05343c1fc3
Subject: Re: [PHP-DEV] [RFC] Replace "Missing argument" warning with "Too few
 arguments" exception
From: nikita.ppv@gmail.com (Nikita Popov)

--001a114897a059270a05343c1fc3
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 1, 2016 at 8:24 PM, Dmitry Stogov <dmitry@zend.com> wrote:

> In the SSA optimisation framework  (part of opcache), we predict and
> propagate types of variables.
>
> We also may detect situations when some variables may be undefined.
>
> If variable can't be "undefined", we may avoid unnecessary run-time checks
> (e.g .like in ZEND_ADD_LONG handler).
>
> Local variables almost always initialized before usage, but with exiting
> behavior, function arguments always may be uninitialized.
>
To expand on this a bit... if a variable is potentially undefined, we
pretty much have to exclude it from optimization entirely, as nearly any
transformation we can make is prone to impact the undefined variable notice
in some way (remove, duplicate, reorder). The saving grace here is that
(untyped) function parameters don't have any type information, so we
typically can't apply transformations anyway (e.g. type specialization is
obviously not applicable, but many other transformation require guaranteed
warning/notice freedom, which usually requires more specific type
information than "any").

However, there are some optimizations that would be applicable if not for
the fact that the variable is potentially undefined. One such example is
copy propagation. Namely, in

function test($param) {
    $var = $param;
    // ...
    use($var);
}

we wouldn't be able to simply replace all uses of $var with $param and save
that assignment, because this might duplicate or reorder "undefined
variable" notices. Such "useless" variable-to-variable assignments are
typically introduced by inlining. (Note: Both copy propagation and inlining
are not currently in php-src, but may well be in the future.)

Nikita

--001a114897a059270a05343c1fc3--