Re: [PHP-DEV] Windows (Visual Studio) compiler stuff
[email protected] ("Matt Wilmas") Mon, 16 Nov 2015 07:58:48 -0600
| Newsgroups | php.internals,php.internals.win |
|---|---|
| Message-ID | <57955F4AAAFF48339CF9194924258215@pc1> |
Hi Anatol, ----- Original Message ----- From: "Anatol Belski" Sent: Monday, November 16, 2015 > Hello Matt, > >> -----Original Message----- >> From: Matt Wilmas [mailto:[email protected]] >> Sent: Sunday, November 15, 2015 11:31 PM >> To: [email protected]; [email protected] >> Cc: Dmitry Stogov <[email protected]>; Anatol Belski > <[email protected]>; >> Pierre Joye <[email protected]> >> 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