Newsgroups: php.internals,php.internals.win
Path: news.php.net
Xref: news.php.net php.internals:89240 php.internals.win:1127
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Matt Wilmas'" <php_lists@realplain.com>,
	<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> <57955F4AAAFF48339CF9194924258215@pc1>
In-Reply-To: <57955F4AAAFF48339CF9194924258215@pc1>
Date: Mon, 16 Nov 2015 21:05:44 +0100
Message-ID: <039701d120aa$300afa50$9020eef0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQEiQ3+JiWbokf3YDWf6nHVaJvz+MACpW1i1AhIw2E6f5pEOIA==
Content-Language: en-us
Subject: RE: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio) compiler stuff
From: anatol.php@belski.net ("Anatol Belski")

Hi Matt,

> -----Original Message-----
> From: Matt Wilmas [mailto:php_lists@realplain.com]
> Sent: Monday, November 16, 2015 2:59 PM
> 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>
> Subject: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio) compiler
> stuff
> 
> > 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."
> 
Yeah, I knew it could work, just that it's undocumented so preferred not
even to start with it because I haven't expect much gain from it. The
functions I've seen with zend_never_inline are rather big and wouldn't get
inlined even when forced.

> > 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.
>
I guess I've understood what you're talking about - abut unreferenced
COMDATs (or maybe also duplicated COMDATs). There is a variety of situations
for that, not possibly only inlining. Fixing it is done in PHP when building
with --enable-debug-pack, that is on in release builds. In your experiments,
if you add /Zi CFLAG (or explicitly /Gy) and /OPT:REF,ICF LDFLAG - that will
solve it for yur other project. You can read more about COMDAT on MSDN.

Hm, probably these options could be revisited, as since 2013 there's also
/Gw and /Zc:inline switches which is not implied by /Zi. But have to do more
checks, for now the release build options are good enough.
 
> Again, I'll try to compile PHP with those static's removed and report the
effect
> later.
> 
Yes, thanks for your effort. I actually didn't check what gcc does for such
cases, so curious. But "static" in "static inline" forces every translation
unit to have even the same function to have different address, thus
eliminating the "one definition" rule for inline. We anyway need "static
inline" best compatibility, the compilers handle the rest :)

Regards

Anatol