Newsgroups: php.internals,php.internals.win
Path: news.php.net
Xref: news.php.net php.internals:89235 php.internals.win:1126
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 68.114.190.31 cause and error)
Message-ID: <57955F4AAAFF48339CF9194924258215@pc1>
To: "Anatol Belski" <anatol.php@belski.net>,
	<internals@lists.php.net>,
	<internals-win@lists.php.net>
Cc: "'Dmitry Stogov'" <dmitry@zend.com>,
	"'Pierre Joye'" <pierre.php@gmail.com>
References: <9B23C6783EE5480CB15EAC35B9E420EA@pc1> <031201d12071$c8f66800$5ae33800$@belski.net>
Date: Mon, 16 Nov 2015 07:58:48 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Windows (Visual Studio) compiler stuff
From: php_lists@realplain.com ("Matt Wilmas")

Hi Anatol,

----- Original Message -----
From: "Anatol Belski"
Sent: Monday, November 16, 2015

> Hello Matt,
>
>> -----Original Message-----
>> From: Matt Wilmas [mailto:php_lists@realplain.com]
>> Sent: Sunday, November 15, 2015 11:31 PM
>> To: internals@lists.php.net; internals-win@lists.php.net
>> Cc: Dmitry Stogov <dmitry@zend.com>; Anatol Belski
> <anatol.php@belski.net>;
>> Pierre Joye <pierre.php@gmail.com>
>> Subject: [PHP-DEV] Windows (Visual Studio) compiler stuff
>>
>> Hi Dmitry, Anatol, Pierre (etc.), and all,
>>
>> I'm back now, I think, after a much longer (unintentional) break than I
> expected.
>> Be coming very soon with what I was doing in the summer (param parsing
> stuff)
>> -- *now* it works with MSVC too, barring any fragility, as I accidentally
>> discovered last month...
>>
>> I've been "discovering" a lot with the wacky Visual Studio compiler! :-)
> This
>> message is about the 2 I found today.
>>
>> The first simple thing was probably just overlooked, but noticed it while
> looking
>> up __declspec.  zend_never_inline has always been empty (I guess) for
> MSVC,
>> but there's actually a __declspec(noinline) that can be used (and works 
>> as
>> expected).  A simple and obvious change to bring it in line with the 
>> other
>> compilers?
>>
> According to the docs __declspec(noinline) is specific to C++. Also with 
> VS
> it's always much more tedious to inline something than the opposite. These
> are the main two reasons it's disregarded ATM. We can add it for 
> compliance
> with C++, but it'll in best case have no effect in the PHP core. Should be
> tested before, though.

Yeah, I know what the docs imply ("member function"), which is why I tested 
it.  I guess you missed my "works as expected" part. :-P

A test function that just returns a number was automatically inlined (plain 
C).  Using __declspec(noinline) it was call'ed instead.

Not sure if any of the "zend_never_inline" PHP stuff is getting inlined when 
it's desired not to be -- I'll compile PHP in a bit and see what it looks 
like with "noinline."

>> The second "issue" is with the zend_always_inline functions, I noticed
> this
>> summer.  Did anyone else know that MSVC leaves a *copy* of those 
>> functions
> in
>> the output files (DLLs)?  What's the point of that?  When they've been
> inlined,
>> and not referenced otherwise, there should be no reason to emit code for 
>> a
>> standalone function!
>>
>> I remembered after seeing that behavior that a bit of my own
> __forceinline'd
>> code did NOT have extra function code, but forgot to investigate until
> today.
>> What's different about my function definition?  No "static"
>> specifier!  So that's the key. :-)
>>
>> But... non-static would create duplicate symbols, I thought.  But no, it
> works!
>> With just __forceinline, there's no errors. :^)
>>
>> Can something be done about this?  It would cut the binary size down a
> bit.
>> A zend_static macro to be used with zend_always_inline...?
>>
> I'd ask you for some concrete case for this, as I'm not sure to understand
> exactly what you mean. The only case where an extra code would be 
> generated
> is with "__declspec(export) inline", but that's not the case anywhere 
> within
> PHP.

My concrete case is checking tons of generated code! ;-)

It's simple: useless standalone functions are created for every "static 
__forceinline" definition...  Not having static makes it act like GCC/Clang.

Again, I'll try to compile PHP with those static's removed and report the 
effect later.

> Regards
>
> Anatol

- Matt