This issue was raised on the sf forum: http://sourceforge.net/p/mingw-w64/discussion/723797/thread/cd8a855f
but I very much prefer to use the mailing list. The problem: marking a class as dllexport prevents the inlining of its class methods. I guess the same applies to inline functions. This has a huge performance impact on C++ code that uses tiny methods (i.e. the setter/getter idiom). I've experienced slowdowns of 4x on real world cases. The OP filed a bug report on GCC: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892 I've experimented with using --export-all-symbols, but it creates duplicate definitions errors when there are several DLLs involved, some of them depending on the others and on the same C++ static libraries. So, in desperation, I dived into GCC sources and hacked the patch below. Obviously, it is not the Right Way of fixing GCC but it "works" and allows me to start considering mingw32-w64 as a substitute for MSVC. Hopefully it is useful to others as a temporary band-aid. For the same project that was 4x slower than when compiled with MSVC, suddenly it becomes clearly faster than the MSVC version when DW2 exceptions are used (using DW2 is cheating on my book, but that's another story.) Modified gcc/integrate.c diff --git a/gcc/integrate.c b/gcc/integrate.c index 3a79183..f6c9e93 100644 --- a/gcc/integrate.c +++ b/gcc/integrate.c @@ -77,6 +77,9 @@ function_attribute_inlinable_p (const_tree fndecl) { const_tree a; + if (lookup_attribute ("dllexport", DECL_ATTRIBUTES (fndecl))) + return true; + for (a = DECL_ATTRIBUTES (fndecl); a; a = TREE_CHAIN (a)) { const_tree name = TREE_PURPOSE (a); (Caveat: yesterday I looked at GCC sources for first time, so saying that I'm a total beginner would be some sort of aggrandizement.) On that function, I was unable to clearly picture what targetm.function_attribute_inlinable_p really aims to. In my experiments it always returns false (it corresponds hook_bool_const_tree_false) which means that the fndecl is not inlineable if it has any attribute. Moreover, I don't understand why it loops through the attributes for deciding the result on a single call whose arguments do not depend on anything inside the loop, except for the decision of calling function_attribute_inlinable_p if fndecl has some attribute. Wouldn't it be simpler to call targetm.function_attribute_inlinable_p without all the looping? ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
