(06-07-2010, 06:56 PM)gregory Wrote: + inline fix: I take the hint of gigaherz. Duplicate the clamp_mix function that cause the failure. With the keyword static gcc is happy and do the inline. However I found an interesting behavior, clamp_mix function (before & after patches) are not inlined in Reverb.cpp. I try to also declare the clamp function (on reverb.cpp) static but it causes some inline error in others places... Opinion are welcome.
This is a limitation of GCC: it does not have global optimizations support (also known as link-time code generation (LTCG)). It will only be able to inline the code within defined modules.
... which means that 90% of the __forceinline specifiers in CSX2 and plugins don't do anything on GCC. I've known this since day 1, but there isn't much I can do about it, because there's no way I'm putting 90% of pcsx2 into one gigantic .cpp/.h buildfile.
I like to keep code out of header files as much as possible because MSVC's debugger gets progressively slower about setting breakpoints and tracing into code, the more times code is included into separate cpp files. Tracing into std::containers can take several seconds even on my good machine (20+ on my lappy), and setting/deleting a breakpoint takes 15+ seconds (over a min on the lappy). Additionally, the more code in header files, the more likely Visual C's intellisense can go buggy and stop working.
Initially I tried to keep a policy of leaving small functions in headers and leaving larger ones in CPP, but PCSX2's so large that it became overwhelming and was getting increasingly difficult for me to remember/decide if I should look for a function's implementation in a cpp or an h, and I frequently ended up with two problem cases:
1. a dozen or more functions of related action, some large and some small, and forced to decide if I should just axe the cpp altogether or axe the .h altogether (since having them split across 2 files were awkward).
2. forward declarations. Places where I have 2 classes inter-dependent on each other, so they'd still need to be fully defined in separate class declarations and method definitions (with implementations typically defined in .inl's, and then specially included after the .h's so that dependencies are properly resolved). This is actually a problem on MSVC, because it causes __forceinline to generate compiler errors. (sigh) So it would fix GCC inlining but break MSVC from even being able to compile.
So finally I decided to bank on a theory:
Linux builds at the time barely worked anyway. It'd prolly be a year before it did. I figured most likely GCC would support LTCG by then; so I favored good C++ design, separating definition and implementation whenever possible. That was more than two years ago.
Unfortunately the 15-25% improvements in speed seen by using LTCG on.. well.. just about any type of program, just isn't enough to motivate the GCC gurus to implement LTCG. They would much rather spend their days implementing things like a 16-byte aligned stack (which is actually slower on x86-32, in addition to being asinine stupid on a few other levels), and then coding tens of thousands of lines of heuristics analysis in order to generate a couple XMM instructions here or there.
Conclusion:
After forcing me to spend a few weeks of my life to backward engineer their undocumented piece of glorified nonsense called "aligned stack on x86-32", I no longer have any will or desire to sacrifice my preferred coding styles for their foolish non-implementations. You're welcome to move clamp_mix to a header file so that GCFail can inline it, but I might just undo it at any time, willingly and without remorse.
Maybe you could do like w32pthreads did for mingw: create a set of "cpp groups" that are basically things like:
#include "mixer.cpp"
#include "adsr.cpp"
...etc.
So long as the cpp files don't create local-scope macros or static variables that are non-unique in name, it should work ok (and generally I try to avoid using non-unique static var names, out of principle -- so there shouldn't be many of them -- if at all).
Oh, and another option!
Ask the GCC gurus for LTCG support! It's a good option if you enjoy being insulted and spat upon anyway.
Jake Stine (Air) - Programmer - PCSX2 Dev Team
Classical case !
