[PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio) compiler stuff

[Matt Wilmas]

Hi Anatol,

- Original Message -
From: "Anatol Belski"
Sent: Wednesday, November 25, 2015


Hi Matt,


-Original Message-
From: Matt Wilmas [mailto:php_li...@realplain.com]
Sent: Monday, November 23, 2015 8:15 AM
To: Anatol Belski ; internals@lists.php.net;

internals-

w...@lists.php.net
Cc: 'Dmitry Stogov' ; 'Pierre Joye'



Subject: Re: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio)

compiler

stuff

Hi Anatol, all,

- Original Message -
From: "Anatol Belski"
Sent: Monday, November 16, 2015

[...]

noinline did have an effect -- 12 KB smaller php7.dll.  So, obviously 
it's

preventing those zend_never_inline functions from being inlined when they
currently are.  Dmitry surely had reason to make them that way --

cache-related,

I assume.  Any difference, however "minor," is the same as other

compilers, so

it's nice to know this can be used, with so many of the other GCC/Clang

"tricks"

missing...


I wasn't telling it wouldn't work. We should check for possible
implications. If there's nothing negative, so we can add this into master.
It always depends, smaller image size vs. function call.


It works and I don't see how there could be implications, so "do it" I say. 
;-)


It doesn't really depend in the case of zend_never_inline -- the *point* is 
to ensure a function call (and smaller code size).  Question/take it up with 
Dmitry otherwise. :-P



BTW, something "big" not getting inlined even when forced?  I know the

"rules"
about what can't be [force] inlined (basically same as GCC) and size 
isn't

one of

them. :-)  (I hope not.)  As I've mentioned a bit, to be seen soon, my

"compile-

time" param parsing optimization will have the "hugest"
inline function, but it compiles down to literally nothing, which I

finally got to

work with MSVC as well.  That's why I wasn't liking the idea of a

standalone copy

of that stuff adding several KB to each module...

Size is one of the factors, the concrete code and usage, too. Despite 
that,

any compiler doc says that inline is just a suggestion.


This is unrelated to anything anyway, but...  We're not talking about "just 
inline" here, but always/force.  Much more than "just a suggestion."  At 
least when optimization is enabled, it WILL be inlined provided it doesn't 
contain one of the things that makes it ineligible for inlining.


So it's more like Arnold in T2: "I insist."  Or, a very strong suggestion.


> 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.

Yeah, I know about the COMDAT stuff.  And I thought I had tried the

/OPT:REF,

etc. on a standalone test a while ago and it didn't do anything...

I just now tried --enable-debug-pack, and as I was thinking, it had no

effect.



What do you mean with "no effect"? Don't reduce size? The compiler/linker
options I've mentioned are about removing identical or unreferenced 
COMDATS,

and they do that. BTW how do you check it? I would like you to be more
precise at this point, please. Did you use link /map or disasm?


No effect meaning it didn't do anything at all.  So no, they didn't remove 
the, what, 220 KB+ worth of code...  File size identical, so I assume all 
contents as well (except image headers, etc.).


I've always been checking file size (for quick answer) and disassembly...


I don't need to solve anything on the other project since I didn't use

static there.

:-P

> 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 :)

First, the report: Removing all the static's with zend_always_inline 
works

fine

(since the __forceinline seems to "imply" static, no duplicate symbols).

It makes

php7.dll 91 KB smaller (NTS --disable-all).

But then when I tried the /Zc:inline option (really sounds like C++ on

MSDN) the

other day, I was pleasantly surprised!  "You da man!" :-)

That saved over 220 KB, without removing static's.  I verified that the

standalone

functions 

[PHP-DEV] RE: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio) compiler stuff

[Anatol Belski]

Hi Matt,

> -Original Message-
> From: Matt Wilmas [mailto:php_li...@realplain.com]
> Sent: Monday, November 23, 2015 8:15 AM
> To: Anatol Belski ; internals@lists.php.net;
internals-
> w...@lists.php.net
> Cc: 'Dmitry Stogov' ; 'Pierre Joye'

> Subject: Re: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio)
compiler
> stuff
> 
> Hi Anatol, all,
> 
> - Original Message -
> From: "Anatol Belski"
> Sent: Monday, November 16, 2015
> 
> > Hi Matt,
> >
> >> -Original Message-
> >> From: Matt Wilmas [mailto:php_li...@realplain.com]
> >> Sent: Monday, November 16, 2015 2:59 PM
> >> To: Anatol Belski ; internals@lists.php.net;
> > internals-
> >> w...@lists.php.net
> >> Cc: 'Dmitry Stogov' ; 'Pierre Joye'
> > 
> >> 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.
> 
> noinline did have an effect -- 12 KB smaller php7.dll.  So, obviously it's
> preventing those zend_never_inline functions from being inlined when they
> currently are.  Dmitry surely had reason to make them that way --
cache-related,
> I assume.  Any difference, however "minor," is the same as other
compilers, so
> it's nice to know this can be used, with so many of the other GCC/Clang
"tricks"
> missing...
> 
I wasn't telling it wouldn't work. We should check for possible
implications. If there's nothing negative, so we can add this into master.
It always depends, smaller image size vs. function call.

> BTW, something "big" not getting inlined even when forced?  I know the
"rules"
> about what can't be [force] inlined (basically same as GCC) and size isn't
one of
> them. :-)  (I hope not.)  As I've mentioned a bit, to be seen soon, my
"compile-
> time" param parsing optimization will have the "hugest"
> inline function, but it compiles down to literally nothing, which I
finally got to
> work with MSVC as well.  That's why I wasn't liking the idea of a
standalone copy
> of that stuff adding several KB to each module...
> 
Size is one of the factors, the concrete code and usage, too. Despite that,
any compiler doc says that inline is just a suggestion.

> >> > 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.
> 
> Yeah, I know about the COMDAT stuff.  And I thought I had tried the
/OPT:REF,
> etc. on a standalone test a while ago and it didn't do anything...
> 
> I just now tried --enable-debug-pack, and as I was thinking, it had no
effect.
> 
What do you mean with "no effect"? Don't reduce size? The compiler/linker
options I've mentioned are about removing identical or unreferenced COMDATS,
and they do that. BTW how do you check it? I would like you to be more
precise at this point, please. Did you use link /map or disasm?

> I don't need to solve anything on the other project since I didn't use
static there.
> :-P
> 
> > Hm, probably 

[PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio) compiler stuff

[Matt Wilmas]

Hi Anatol, all,

- Original Message -
From: "Anatol Belski"
Sent: Monday, November 16, 2015


Hi Matt,


-Original Message-
From: Matt Wilmas [mailto:php_li...@realplain.com]
Sent: Monday, November 16, 2015 2:59 PM
To: Anatol Belski ; internals@lists.php.net;

internals-

w...@lists.php.net
Cc: 'Dmitry Stogov' ; 'Pierre Joye'



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.


noinline did have an effect -- 12 KB smaller php7.dll.  So, obviously it's 
preventing those zend_never_inline functions from being inlined when they 
currently are.  Dmitry surely had reason to make them that way --  
cache-related, I assume.  Any difference, however "minor," is the same as 
other compilers, so it's nice to know this can be used, with so many of the 
other GCC/Clang "tricks" missing...


BTW, something "big" not getting inlined even when forced?  I know the 
"rules" about what can't be [force] inlined (basically same as GCC) and size 
isn't one of them. :-)  (I hope not.)  As I've mentioned a bit, to be seen 
soon, my "compile-time" param parsing optimization will have the "hugest" 
inline function, but it compiles down to literally nothing, which I finally 
got to work with MSVC as well.  That's why I wasn't liking the idea of a 
standalone copy of that stuff adding several KB to each module...



> 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.


Yeah, I know about the COMDAT stuff.  And I thought I had tried the 
/OPT:REF, etc. on a standalone test awhile ago and it didn't do anything...


I just now tried --enable-debug-pack, and as I was thinking, it had no 
effect.


I don't need to solve anything on the other project since I didn't use 
static there. :-P



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 :)


First, the report: Removing all the static's with zend_always_inline works 
fine (since the __forceinline seems to "imply" static, no duplicate 
symbols).  It makes php7.dll 91 KB smaller (NTS --disable-all).


But then when I tried the /Zc:inline option (really sounds like C++ on MSDN) 
the other day, I was pleasantly surprised!  "You da man!" :-)


That saved over 220 KB, without removing static's.  I verified that the 
standalone functions (from static's) were gone, but obviously it also 
removed a lot more.  Thank you!


Hopefully that's a switch that can be taken advantage of?


Regards

Anatol


Thanks,
Matt 



--
PHP Internals - PHP 

[PHP-DEV] RE: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio) compiler stuff

[Anatol Belski]

Hi Matt,

> -Original Message-
> From: Matt Wilmas [mailto:php_li...@realplain.com]
> Sent: Monday, November 16, 2015 2:59 PM
> To: Anatol Belski ; internals@lists.php.net;
internals-
> w...@lists.php.net
> Cc: 'Dmitry Stogov' ; 'Pierre Joye'

> 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 



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php