Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83523
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7d58f9b893c257c7289166b31bbdd9ac@mail.gmail.com>
References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com>
	<CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>
	<83921f861c3378dfc6ea34b6681f2edd@mail.gmail.com>
	<CAAyV7nEhdeXQbUi9jy10M1NyfaV-w1kF=nWeSW0zd8UQh2_dJQ@mail.gmail.com>
	<26a5bb62bd37a3f610b2a6c10f84d855@mail.gmail.com>
	<CAAyV7nEf_q_NkoQrWN1pa_ot8Ype-SCdvJOdpevUsd4y8Kv6pA@mail.gmail.com>
	<6d317b6cce0cc1aaded1dae11218234d@mail.gmail.com>
	<CAAyV7nFcGWJOj-R3ZEn8XkGFqzuw1Ef3tx3Ykm3AXg6KxB+wHg@mail.gmail.com>
	<7d58f9b893c257c7289166b31bbdd9ac@mail.gmail.com>
Date: Sun, 22 Feb 2015 20:20:58 -0500
Message-ID: <CAAyV7nEoRfPi9u+2OhfZeuTpNJ+innmyajiEYRGSbX+zOP_4Dg@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
From: ircmaxell@gmail.com (Anthony Ferrara)

Zeev,


>> 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?

Yes. At least for what I was talking about in this thread.

>> 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?

Once you get to the end, no. Recki-CT proves that.

The difference though is the journey. The static analyzer can reason
about far more code with strict types than it can without (due to the
limited number of possibilities presented at each call). So this
leaves the dilema: compiled code that behaves slightly differently
(what Recki does) or whether it always behaves the same.

>> 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?

Basically yes.

Anthony