Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83502
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.49 as permitted sender)
Message-ID: <54EA5EDA.8010605@gmail.com>
Date: Sun, 22 Feb 2015 14:57:30 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>, Zeev Suraski <zeev@zend.com>
CC: Jefferson Gonzalez <jgmdev@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com> <CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>
In-Reply-To: <CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

>> -- Can the code generated for a strict type hint can somehow be optimized
significantly better than the code generated for a dynamic/coercive type
hint.
> And me, who wrote an AOT compiler that does **exactly** this, claim

Sorry, did exactly what? Here a bit more explanation would help.

> However, since test_strict() is compiled, there's no reason to
> dispatch back up to PHP functions for strict_foo(). In fact, that
> would be exceedingly slow. So instead, we'd compile strict_foo() as a
> C function, and do a native function call to it. Never having to check
> types because they are passed on the C stack.

Doesn't that assume strict_foo() is always called with the right type of
arguments? What exactly ensures that it does in fact happen? Shouldn't
you have the type check _somewhere_ to be able to claim this happens?
test_foo() doesn't do any checks, so what ensures $x is of the right
type for C? And if the check is there, how is it better?

> 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).

I don't get the backwards part - I think you claimed it last time we
discussed it but I haven't seen your answer explaining why it's OK to
just ignore cases when the variable is of the wrong type. Right now, it
looks like you claim that if somebody has a call strict_foo($x) and
strict_foo() accepts integers, that magically makes $x integer and you
can generate code everywhere (not only inside strict_foo but outside)
assuming $x is integer without actually needing a check. I don't see how
this can work.
-- 
Stas Malyshev
smalyshev@gmail.com