Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87662
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <FB306BE4C2EC44079EF5B67ABA33B379@pc1>
References: <CAGa2bXY1hKW3qX3jBwKge7RDihS6TjxAW3p+-kKRiW4OmePLSQ@mail.gmail.com>
	<CAH-PCH6YtrM8B1DBWXL7+5mfgUROKKwqFd2VDL+FZtUEfRpREw@mail.gmail.com>
	<CA+9eiLsrG5TiFEv=2NQPTQxcvMZD9gd0bQLsn7xMQU7HU-oaYQ@mail.gmail.com>
	<051CB45EE4B24C7C88C3EABC7E8EE0A2@pc1>
	<CA+9eiLv1zQtxyWyOU-ORRvmsuFyUFtys2jHLGkgmMJUgqEo0qQ@mail.gmail.com>
	<BEDC662A786B499C8092F7AA75E9D085@pc1>
	<CA+9eiLucOc-qZxBD7UqEhxsySUK4fkG4A_zDj4zWhF2cGkAydg@mail.gmail.com>
	<E73C9C17C6F14925BF79435803FFED45@pc1>
	<77CE51405C92499BA13CE0913883EE05@pc1>
	<CA+9eiLsoaunqSibHZGOX0L+epcTM5FZZGWSndAyUt7ssTk-3pw@mail.gmail.com>
	<BA818BDA0D2A43DAA4329D1A66810B43@pc1>
	<CAFMT4Nq4ofMO_n8i01RscFrx0bbkuD2i4LygOkQAYLve0-vMuQ@mail.gmail.com>
	<FB306BE4C2EC44079EF5B67ABA33B379@pc1>
Date: Thu, 6 Aug 2015 13:59:18 +0700
Message-ID: <CAEZPtU5mQANsf7qohyBbNe-X1wLbmFnS_tvdkgoU40HbQE7esQ@mail.gmail.com>
To: Matt W <php_lists@realplain.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, Ferenc Kovacs <tyra3l@gmail.com>, 
	PHP Internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>, Levi Morrison <levim@php.net>
Content-Type: multipart/alternative; boundary=089e0160bf68e24d8e051c9f0eb7
Subject: Re: [PHP-DEV] Move to Fast ZPP?
From: pierre.php@gmail.com (Pierre Joye)

--089e0160bf68e24d8e051c9f0eb7
Content-Type: text/plain; charset=UTF-8

On Aug 6, 2015 1:49 PM, "Matt Wilmas" <php_lists@realplain.com> wrote:
>
> Hi Levi,
>
>
> ----- Original Message -----
> From: "Levi Morrison"
> Sent: Thursday, August 06, 2015
>
>>> Don't know about Windows now...  Visual Studio 2008 and 2012 (not much
>>> difference) are NOT optimizing away the code (other times it was GCC
with
>>> issues). :-/  Not sure why.  Of course they don't support the necessary
>>> compound literals anyway, but I was just testing a manual case...  I'll
have
>>> to try and check 2015 version soon.
>>
>>
>> VS 2015 supports compound literals, I believe.
>
>
> Yes, VS 2013 added, AFAIK.  But I was just talking about optimizing the
code that would use them.  A compound literal (void *[]), derived from
variadic macro, is needed to transform zend_parse_parameters() into a
non-varargs inline function call (since va_arg usage prevents inlining).
>
> The problem in the earlier VS versions, which I simulated manually
without compound literals, is that it doesn't want to optimize away all the
inlined stuff, leaving only the result.  Definitely can't have something
creating several KB of extra instructions! :-)
>
> So unless they improved something in the newest versions, this wouldn't
be able to be used there, unless I can work around it somehow.  I don't
know if macros, instead of inline functions, inside the main inline
function would help or not...
>
> Although, it *would* simplify a couple tiny parts if didn't need to
support MSVC...  First, detecting a string *literal* (99% of usage): could
just use __builtin_constant_p() instead of a macro trick.
>
> And second, using a variable length array, with size set by, well, a
variable, which I think VS still doesn't support from C99, right?  (It's
for a "variable" in this case, but always the same, so should optimize like
a compile-time size.)

If you have a piece of self contained code to test it, we can then add it
to the VC test repo to valid what we can support with 7+.

--089e0160bf68e24d8e051c9f0eb7--