Newsgroups: php.internals,php.internals.win
Path: news.php.net
Xref: news.php.net php.internals:89312 php.internals.win:1131
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CD9F6A36D2EF4A529EDAFE5C8A4E6929@pc1>
References: <9B23C6783EE5480CB15EAC35B9E420EA@pc1>
	<CA+9eiLvLZpY8-Z5JjkzUuHjyBJs2FMor9ZYb1cyV26Tc=wvEzA@mail.gmail.com>
	<CD9F6A36D2EF4A529EDAFE5C8A4E6929@pc1>
Date: Mon, 23 Nov 2015 11:31:06 +0300
Message-ID: <CA+9eiLtb+RRuL4bHn0QzMrsc8ezn2Kog1=HEMZeb1Dm6hvA_Ww@mail.gmail.com>
To: Matt Wilmas <php_lists@realplain.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>
Content-Type: multipart/alternative; boundary=001a1140f378de39320525310bed
Subject: Re: [PHP-DEV] Re: Windows (Visual Studio) compiler stuff
From: dmitry@zend.com (Dmitry Stogov)

--001a1140f378de39320525310bed
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 23, 2015 at 8:08 AM, Matt Wilmas <php_lists@realplain.com>
wrote:

> 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.)
>

I don't test Windows builds.
If this OK for Anatol - just commit this.

Thanks. Dmitry.


>
> 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
>

--001a1140f378de39320525310bed--