Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83507
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <83921f861c3378dfc6ea34b6681f2edd@mail.gmail.com>
References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com>
	<CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>
	<83921f861c3378dfc6ea34b6681f2edd@mail.gmail.com>
Date: Sun, 22 Feb 2015 18:35:14 -0500
Message-ID: <CAAyV7nEhdeXQbUi9jy10M1NyfaV-w1kF=nWeSW0zd8UQh2_dJQ@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,

>> And note that this can only work with strict types since you can do the
>> necessary type inference and reconstruction (both forward from a function
>> call, and backwards before it).
>
> Please do explain how strict type hints help you do inference that you
> couldn't do with dynamic type hints.  Ultimately, your whole argument hinges
> on that, but you mention it in parentheses almost as an afterthought.
> I claim the opposite - you cannot infer ANYTHING from Strict STH that you
> cannot infer from Coercive STH.  Consequently, everything you've shown, down
> to the C-optimized version of strict_foo() can be implemented in the exact
> same way for very_lax_foo().  Being able to optimize away the value
> containers is not unique to languages with strict type hints.  It's done in
> JavaScript JIT engines, and it was done in our JIT POC.

I do here: http://news.php.net/php.internals/83504

I'll re-state the specific part in this mail:

<?php declare(strict_types=1);
function foo(int $int): int {
    return $int + 1;
}

function bar(int $something): int {
    $x = $something / 2;
    return foo($x);
}

^^ In that case, without strict types, you'd have to generate code for
both integer and float paths. With strict types, this code is invalid.

You can tell because you know the function foo expects an integer. So
you can infer that $x will have to have the type integer due to the
future requirement. Which means the expression "$something / 2" must
also be an integer. We know that's not the case, so we can raise an
error here.

At that point the developer has the choice to explicitly cast or put
in a floor() or one of a number of options.

The function "bar" itself didn't give us that information. We needed
to use the type information from foo() to infer the type of $x prior
to foo()'s call. Or more specifically, we inferred the only stable
type that it could be. Which let us determine that $x's assignment was
where the error was (since it wasn't a stable assignment).

Without strict typing this code is always stable, but you still need
to generate full type assertions in a compiled version of foo() and
use ZVALs for $x, hence reducing the effect of the optimization
significantly.

Anthony