Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107727
To: Rowan Tommins <rowan.collins@gmail.com>, internals@lists.php.net
References: <DC8C0F88-1B43-4601-A3D1-2EEA812B89B9@newclarity.net>
 <9d3f9895-5ab6-1d75-4eb2-0ba93f13a8fe@gmail.com>
Message-ID: <393e5c3c-9902-f6ed-bbb1-5ba48294168c@xs4all.nl>
Date: Tue, 29 Oct 2019 22:44:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <9d3f9895-5ab6-1d75-4eb2-0ba93f13a8fe@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Optional pre-compiler for PHP8?
From: d.takken@xs4all.nl (Dik Takken)

On 28-10-19 00:04, Rowan Tommins wrote:
> - a static analyser that can infer types in a PHP program; we know
> that's possible from a number of third-party tools, although they do
> rely on docblock comments for things the language doesn't (yet) let you
> define

Opcache already performs type inference. It does not make use of
information in comments. It only looks at the code, yielding type
information that is accurate and can be used for optimization.

Here is an interesting read on the subject:

https://depositonce.tu-berlin.de/bitstream/11303/7919/3/popov_etal_2017.pdf

> The first problem is that OpCache is designed to work one file at a
> time, because a program can load any combination of files at run-time.
> Static analysers, on the other hand, need to process a whole directory
> at a time, so that calls can be matched to definitions; multiple
> definitions of the same function or class tend to cause problems, even
> though only one is loaded at run-time. So we'd probably need some
> built-in definition of a "package", which could be analysed and compiled
> as one unit, and didn't rely on any run-time loading.

This problem could possibly be solved by using preloading. The
definition of a package would then be: the set of files that the
application will load during startup. Preloading could give opcache
access to the full application and optimize more effectively.

> The second problem is that, as I understand it, type checks aren't
> actually separate OpCodes, so eliminating them from the compiled program
> may not be that easy. There are some cases where you can just eliminate
> the type check from a definition, e.g.:

This is partially correct. Some type checks are separate opcodes, some
are not. Type checking opcodes are actually removed by opcache when its
static analysis can prove that the type check will always pass. It has
some limitations but the functionality is all there.

Regards,
Dik Takken