richardleach
commented
4 days ago If the consensus is that this is the way to go, then I'm happy to go with the flow. However, it does seem like a lot of added complexity basically for the benefit of MSVC, which (as I understand it from comments elsewhere) isn't used to compile any of the major perl distributions.
Additionally, there doesn't seem to have been any discussion of whether MSVC produces better code with different OPTIMISE flags. The current flags have been in place for a touch over a decade, I think in a commit by OP:
# Enable Whole Program Optimizations (WPO) and Link Time Code Generation (LTCG).
# -O1 yields smaller code, which turns out to be faster than -O2 on x86 and x64
OPTIMIZE = -O1 -Zi -GLI wonder if -O1 being better is still true on today's MSVC and average hardware, compared with that of the time.
@bulk88 - do you have any data points on the current vs other sets of OPTIMIZE flags at all?
jkeenan
bulk88
success!!!, new rule, "struct body_details bodies_by_type[]" only in sv.c
-svfix.pl is quick throwaway garbage done in 20 mins and probably doesnt regen sv_inline.h properly and copy pasting/replace regexps were was used anyway to fix up the code, it can be rewritten correctly tho and put in as a official regen.pl script
how to finish this fix, options
set and unset sv_type as a CPP macro then
-#include a header 17 times that contains ONLY only Perl_newSV_type() and its mortal() sister creating 17*2 static inline fns (basically what I did here), code is stepable, extra ms'es of I/O build times perf degrade debate may or may not come up, I hope the CC has a sane in memory cache for .h files and doesn't go back to the kernel
or put the entire Perl_newSV_type() fnc in a #define
then execute that macro 17 times
or write 17 Perl_newSV_type() copies into sv_inline.h with /regen.pl infrastructure (fastest for build speed core and build speed CPAN and code is c dbg stepable) OR is a dedicated "sv_newg.h" for regen.pl needed? does the master Perl_newSV_type() template live in a .pl or a .h? i dont have an opinion
or against concept of sv_inline.h just have 5-10 hand written versions sv type specific of Perl_newSV_type(), its a cheap gimick fix to keep all 17 types together mashed with if/else/switch in 1 func and expecting bug free perfection from LTO engines of various C compilers, and expecting perfection from an single vendor LTO engine is very against the spirit of portable code
-todo ideas, turn those super long #define ==?:==?:==?: into char array/struct initializers, stored in macros, one faux-string per each column of struct body_details, use that macro as c auto stk rw array initializer, then do the
or
which in perl core would look
maybe VC will optimize those since no global memory is used. Only Perl_newSV_typeX() needs this.
in this commit static inline Perl_newSVtypeX(pTHX const svtype type) which is the ONLY Perl_newSV_type*() variant that take an arbitrary svtype arg, this is the fallback for gv_pvn_add_by() since I couldn't "const" that call to newSV_type() cuz gv_pvn_add_by() is only place in the whole core that takes a random SV type number.
Internals of Perl_newSV_typeX() are trashy, here is an example, MSVC DID not turn this into a jump table but instead 17 test/cond_jump ops.
Solution is move Perl_newSV_typeX() to sv.c, and let it be struct body_details driven. Cuz it only purpose is when newSV_type() absolutly CAN NOT be constant folded (random number input). it only has 1 caller in core.
S_new_body() properly const folded away in 99% of cases except for TWO callers Perl_newSV_typeX() and Perl_make_trie(). Perl_make_trie() failure to inline is bizzare, since Perl_make_trie() internally does
v9 = S_new_body(SVt_PVAV);and DID inline Perl_newSV_typeSVt_PVAV() !!! and therefore Perl_make_trie() has the AV field initing/nulling code.
Here is the "optimized" contents of S_new_body(), its junk performance/design wise (but runtime correct/no bugs)
disassembly view of S_new_body()
17 test ops and 17 conditional_move_constant_8_bits ops
solution, turn S_new_body() back into a macro so no CC ever tries to ref-inline it. It was a macro before sv_inline.h branch was merged
TODO add XSApitest.xs that worlds longest macros are identical to the master correct copy (struct body_details).
byte size drops from before these 3 commits to this "success commit"
mp.exe 0x1241AC-0x1224EC=7360 0x19D3D8-0x19B8E8=6896
p541.dll 0x154886-0x1532A6=5600 0x1AA19E-0x1A862E=7024
BEFORE
Dump of file ..\miniperl.exe SECTION HEADER #1 .text name 1241AC virtual size SECTION HEADER #2 .rdata name 19D3D8 virtual size
Dump of file ..\perl541.dll SECTION HEADER #1 .text name 154886 virtual size SECTION HEADER #2 .rdata name 1AA19E virtual size
AFTER
Dump of file ..\perl541.dll SECTION HEADER #1 .text name 1532A6 virtual size SECTION HEADER #2 .rdata name 1A862E virtual size
Dump of file ..\miniperl.exe SECTION HEADER #1 .text name 1224EC virtual size SECTION HEADER #2 .rdata name 19B8E8 virtual size