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