Newsgroups: php.internals,php.internals.win
Path: news.php.net
Xref: news.php.net php.internals:89305 php.internals.win:1129
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 68.114.190.28 cause and error)
Message-ID: <CD9F6A36D2EF4A529EDAFE5C8A4E6929@pc1>
To: "Dmitry Stogov" <dmitry@zend.com>
Cc: "PHP Internals" <internals@lists.php.net>,
	<internals-win@lists.php.net>,
	"Anatol Belski" <anatol.php@belski.net>,
	"Pierre Joye" <pierre.php@gmail.com>
References: <9B23C6783EE5480CB15EAC35B9E420EA@pc1> <CA+9eiLvLZpY8-Z5JjkzUuHjyBJs2FMor9ZYb1cyV26Tc=wvEzA@mail.gmail.com>
Date: Sun, 22 Nov 2015 23:08:00 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Windows (Visual Studio) compiler stuff
From: php_lists@realplain.com ("Matt Wilmas")

Hi Dmitry,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Monday, November 16, 2015

> Hi Matt,
>
> On Mon, Nov 16, 2015 at 1:30 AM, Matt Wilmas <php_lists@realplain.com>
> wrote:
>
>> 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?
>>
>
> Please, provide a patch for zend_portability.h

Really? :-)  And that's easier than just adding

__declspec(noinline)

to line 287?

I can add it myself soon, if it's acceptable.  And yes, I verified that it 
does have an effect, and prevents current inlining, as you intended.  (12 KB 
smaller binary.)

>> 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...?
>>
>
> zend_always inline should be always used with static keyword.

Right, that would be the standard thinking, but it makes MSVC not remove the 
unreferenced standalone function like GCC/Clang...  Adds almost 100 KB to 
php7.dll.

But nevermind...  Thanks to Anatol, it seems another compiler flag WILL 
actually strip those functions, and then some! :-)

> Thanks. Dmitry.

- Matt