Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83520 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12766 invoked from network); 23 Feb 2015 01:14:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Feb 2015 01:14:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=zeev@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=zeev@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.174 as permitted sender) X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 209.85.223.174 mail-ie0-f174.google.com Received: from [209.85.223.174] ([209.85.223.174:32963] helo=mail-ie0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 91/C2-33016-0EE7AE45 for ; Sun, 22 Feb 2015 20:14:08 -0500 Received: by iecar1 with SMTP id ar1so20030821iec.0 for ; Sun, 22 Feb 2015 17:14:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=UnhPJU76Ez1pvUAf63pZADc/lG/Thwv7l2v1fShTYSA=; b=FZCGKiNraFgVxAKJVrz8UW+9yx+NoJXldlL6zESAeUlnwjN7gm+k4oNVCPJ1/um/e/ tosZSmKrJshtBH04HCyEsTJK4ubDW7iM8l2v2pGqYzzjR/RgdAQAcjixtsGaEp/HEw28 FLBRy6Txr81K3DkUIPhsZe3xlWKHw9sdRwMikiQrwUJKT3++mZC1e3dzaEQVFu/iwIxv IguKUod8WsiQkQQMVLj29c1Xa4tKfK4rWlnzqTSZf/LiMqAGaLXDvcjNXWjrXwoOJV6S sPKugfx6J4XaXwZKI+z067ComP82vuyeVfEcGHTUIh5uK1/aNHiCmJvOiUyAewOc2ZLY 6eUA== X-Gm-Message-State: ALoCoQm68fssghqMVK7xN4D+xaXXeZyOElp9ek9y/+4OXwcmg46nYr9il92cOWGyhlGTerDtAsEGLxeWjI5PmScb/5gQZasfdirbSU/y+NwcFYATok97TsYHgFwK15L0gt8FgvRaTdiOWlBImAtQLt4zy345yPLWBg== X-Received: by 10.107.15.96 with SMTP id x93mr10881798ioi.75.1424654045847; Sun, 22 Feb 2015 17:14:05 -0800 (PST) References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com> <83921f861c3378dfc6ea34b6681f2edd@mail.gmail.com> <26a5bb62bd37a3f610b2a6c10f84d855@mail.gmail.com> <6d317b6cce0cc1aaded1dae11218234d@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDXD7ehmaYKzbAddTs7O1sB4MzmgIw+OLdAfG9oisCHTTwrQKy9+dWAdPf8sIB5yj4egFvLJYPnCZoPUA= Date: Mon, 23 Feb 2015 03:14:04 +0200 Message-ID: <7d58f9b893c257c7289166b31bbdd9ac@mail.gmail.com> To: Anthony Ferrara Cc: PHP internals Content-Type: text/plain; charset=UTF-8 Subject: RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC) From: zeev@zend.com (Zeev Suraski) > -----Original Message----- > From: Anthony Ferrara [mailto:ircmaxell@gmail.com] > Sent: Monday, February 23, 2015 3:02 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Zeev, > > > I think we are indeed getting somewhere, I hope. > > If I understand correctly, effectively the flow you're talking about > > in your example is this: > > > > 1. The developers tries to run the program. > > 2. It fails because the static analyzer detects float being fed to an > > int. > > 3. The user changes the code to convert the input to int. > > 4. You can now optimize the whole flow better, since you know for a > > fact it's an int. > > > > Did I describe that correctly? > > Partially. > > The static analysis and compilation would be pure AOT. So the errors would > be told to the user when they try to analyze the program, not run it. > Similar > to HHVM's hh_client. How about that then: 1. The developers runs a static analyzer on the program. 2. It fails because the static analyzer detects float being fed to an int. 3. The user changes the code to convert the input to int. 4. You can now optimize the whole flow better, since you know for a fact it's an int. Is that an accurate flow? > However, there could be a "runtime compiler" which compiles in PHP's > compile flow (leveraging opcache, etc). In that case, if the type > assertion > isn't stable, the function wouldn't be compiled (the external analyzer > would > error, here it just doesn't compile). Then the code would be run under the > Zend engine (and error when called). Got you. Is it fair to say that if we got to that case, it no longer matters what type of type hints we have? > >> With strict typing at the foo() call site, it tells you that $input > >> has to be an int or float (respectively between the snippets). > > > > I'm not following. > > Are you saying that because foo() expects an int or float > > respectively, $input has to be int or float? What if $input is really > > a string? Or a MySQL connection? > > So think of it as a graph. When you start the type analysis, there's one > edge > between $input and foo() with type mixed. Looking at foo's argument, you > can say that the type of that graph edge must be int. > Therefore it becomes an int. Then, when you look at $input, you see that > it > can be other things, and therefore there are unstable states which can > error > at runtime. So when you say it 'must be an int', what you mean is that you assume it needs to be an int, and attempt to either prove that or refute that. Is that correct? If you manage to prove it - you can generate optimal code. If you manage to refute that - the static analyzer will emit an error. If you can't determine - you defer to runtime. Is that correct? For now only focusing on these two parts so that we can make some progress; May come back to others later... Thanks, Zeev