Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107710 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 67261 invoked from network); 28 Oct 2019 01:17:38 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 28 Oct 2019 01:17:38 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 7A4E92C3E4E for ; Sun, 27 Oct 2019 16:04:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: X-Spam-Virus: No Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Sun, 27 Oct 2019 16:04:52 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id p4so7947590wrm.8 for ; Sun, 27 Oct 2019 16:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=LZxAZK9dlps7hq5zGNjGFjwjD0LuD5gbEOhpmbwv9Qo=; b=JUvjaQabAiQd4JDjManCqmqlmhMFLcvrZkuUGrT7BdimmnUWObGAhl9uH+eh2H/BOD COI4L7L6vaxxYL35ZsVvGby0gtwZdNnRSqKtYNeuTtfDQKmL+mSMS0bINSxreqC9547u QuRimTZQXUzsuwtAoyAw5rvZT3vidXr0Sr28P3r4lJhyZ7aTZaivhfXlKckKQWJz67mx +I4sge31jPgv1ql5amoQebNVqY7Jm2nmaQtYqcHkA/BYjG4b1c8ys1HyfkeJdNed7bsn qMvhDF4A0vH3YLqzsho+8arDIDGEFCwyJJi8cIkcUZBxBwasTjE7IHassibZxD6sDdtn pt3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=LZxAZK9dlps7hq5zGNjGFjwjD0LuD5gbEOhpmbwv9Qo=; b=YxAFQB98ILvqzYGWJR4H4JyOmGIZ1PhYfdJRUXdv8zpMt+ZFLkidVeK/jETqymE42T S2rzn0GKxCaNJ+66BH5r2M7CH1LR7WHCv8jgIdlE9JOkutjthQiXvntHx6baP8/dRYXs i8XQEoBlVOTIwAId6hCwWfL4L8j3wjQxEvxgiurt9zitqC5/WLyiMxwt59XnfFSCGjNb smONgfD19NQsNdaKyxcQTOsFkPmCPXNCcQwYf+UdKYxpVKccrDAyKq7/a2Ae+rL0T1ec 0M2fR++KQAZQP21vt4b1l8W19tCUm92PznK9jxqdX+TMqYb3e+RFhCLjAssFTpx/CVRi guSg== X-Gm-Message-State: APjAAAWKxf8X/emSOUhMKlZGWe0FSMxo5LdpDNhVsoSCa3Z5Hsxv7NtW 4OSxSXiBWon4ki5NJyTNSFR3fDP4q5M= X-Google-Smtp-Source: APXvYqyW+95dSUZ/HrZjlJXou4+bZBSll7m6GA3krLg04gz2wDabZgbGzMvNfIIS6Qaxvn2uqZPgkg== X-Received: by 2002:adf:fcd1:: with SMTP id f17mr13435274wrs.82.1572217491534; Sun, 27 Oct 2019 16:04:51 -0700 (PDT) Received: from [192.168.0.16] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.googlemail.com with ESMTPSA id t4sm8431439wmi.39.2019.10.27.16.04.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Oct 2019 16:04:50 -0700 (PDT) To: internals@lists.php.net References: Message-ID: <9d3f9895-5ab6-1d75-4eb2-0ba93f13a8fe@gmail.com> Date: Sun, 27 Oct 2019 23:04:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Envelope-From: Subject: Re: [PHP-DEV] Optional pre-compiler for PHP8? From: rowan.collins@gmail.com (Rowan Tommins) On 27/10/2019 02:12, Mike Schinkel wrote: > While reading the [RFC] Union Types v2 thread and comments from Dmitry[1], and especially Benjamin[2] who suggested "building a static analysis tool which could prove that certain type checks would never fail, and prime OpCache" it occurred to me that a PHP pre-compiler could potentially be used to resolve numerous issues the community has been debating. I chose the phrase "static analysis tool" deliberately, because I wanted to think about the minimum requirements for such a tool, rather than its long-term possibilities. The basic requirements are fairly straight-forward: - 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 - the ability to generate OpCodes for some code and store it to disk; this is more or less what OpCache does if enabled for CLI mode However, combining those usefully may not be that easy. 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. 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.: class A {     private int $x=1;     private function foo(int $x) { }     public function bar() {        $this->foo($this->x);     } } Since we know that function foo is only ever called with the correctly typed argument, we can compile it as though it had no type declaration. However, in the seemingly obvious case Benjamin gave, the optimisation isn't so easy: function x(): int {} function y(int $foo) {} y(x()); We can't eliminate the type check for all calls to x(), or for all calls to y(), but we want to eliminate the duplicate check for that particular line. So the OpCodes need to represent that somehow. I've no idea how easy or hard that would be. In order to extend this to a full compiler, we need at least one more thing: a stable compilation target. What I mean by that is that if I distribute a package in binary form, it needs to run on a reasonably large range of PHP versions and installations. My understanding is that the OpCodes in the Zend VM are not designed to be stable across versions, so you can't just ship today's OpCache output like you would a Java class file or .net assembly. Again, I don't know how much effort it would be to make the VM work as such a stable target. > 4. Ability to deprecate features for pre-compiled code while still supporting them when not precompiled. Unlike P++, Editions, or Strict Mode, this would undeniably define that the deprecated features were "the wrong way". If the engine had to support the feature anyway, I'm not sure what the advantage would be of tying it to "compiled vs non-compiled", rather than opting in via a declare() statement or package config. Regards, -- Rowan Tommins (né Collins) [IMSoP]