Hi Anatol,
----- Original Message -----
From: "Anatol Belski"
Sent: Monday, November 16, 2015
Hello Matt,
-----Original Message-----
From: Matt Wilmas [mailto:php_li...@realplain.com]
Sent: Sunday, November 15, 2015 11:31 PM
To: internals@lists.php.net; internals-...@lists.php.net
Cc: Dmitry Stogov <dmi...@zend.com>; Anatol Belski
<anatol....@belski.net>;
Pierre Joye <pierre....@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
