Re: r260267 - Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp
On Tue, Feb 9, 2016 at 2:53 PM, Reid Kleckner via cfe-commitswrote: > Author: rnk > Date: Tue Feb 9 13:53:30 2016 > New Revision: 260267 > > URL: http://llvm.org/viewvc/llvm-project?rev=260267=rev > Log: > Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp > > This is the third time it has crossed the 2^16 section limit. We've > already spent time optimizing this file to reduce template > instantiations, and it's not clear that there is anymore low hanging > fruit. Bummer. Do we have any mechanisms in place that will bark loudly at us when we accidentally introduce a large quantity of symbols from this file now? That has also happened a few times, and /bigobj warnings were the primary way we were notified (since it's difficult to tell from file size alone). ~Aaron > > Modified: > cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt > > Modified: cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt?rev=260267=260266=260267=diff > == > --- cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt (original) > +++ cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt Tue Feb 9 13:53:30 2016 > @@ -1,5 +1,14 @@ > set(LLVM_LINK_COMPONENTS support) > > +# The registry source file ends up generating a lot of sections for each > +# matcher. Each matcher appears to get a vtable and several methods. Each > +# method needs .text, .pdata, .xdata, and .debug sections, adding to the > +# section multiplier. By default MSVC has a 2^16 limit on the number of > +# sections in an object file, and this needs more than that. > +if (MSVC) > + set_source_files_properties(Registry.cpp PROPERTIES COMPILE_FLAGS /bigobj) > +endif() > + > add_clang_library(clangDynamicASTMatchers >Diagnostics.cpp >VariantValue.cpp > > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r260267 - Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp
On Tue, Feb 9, 2016 at 3:59 PM, Reid Klecknerwrote: > On Tue, Feb 9, 2016 at 12:32 PM, Aaron Ballman > wrote: >> >> On Tue, Feb 9, 2016 at 2:53 PM, Reid Kleckner via cfe-commits >> wrote: >> > Author: rnk >> > Date: Tue Feb 9 13:53:30 2016 >> > New Revision: 260267 >> > >> > URL: http://llvm.org/viewvc/llvm-project?rev=260267=rev >> > Log: >> > Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp >> > >> > This is the third time it has crossed the 2^16 section limit. We've >> > already spent time optimizing this file to reduce template >> > instantiations, and it's not clear that there is anymore low hanging >> > fruit. >> >> Bummer. Do we have any mechanisms in place that will bark loudly at us >> when we accidentally introduce a large quantity of symbols from this >> file now? That has also happened a few times, and /bigobj warnings >> were the primary way we were notified (since it's difficult to tell >> from file size alone). > > > No, there isn't any mechanism. I think what we really should be worrying > about is overall code size, and that this particular section count limit is > arbitrary. It is definitely sub-optimal and arbitrary, yet it has pointed out real problems in the past that we would be unlikely to catch as quickly, so it was better than nothing. Note, I am not suggesting this commit is inappropriate, just unfortunate. > If we tackled the code size problem directly, we'd use a tool to highlight > code that has a high source-line-to-code-byte ratio. I know Chromium has > done this in the past to identify overly inlined functions and things that > shouldn't be templates. That would definitely be useful functionality! ~Aaron ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r260267 - Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp
On Tue, Feb 9, 2016 at 12:32 PM, Aaron Ballmanwrote: > On Tue, Feb 9, 2016 at 2:53 PM, Reid Kleckner via cfe-commits > wrote: > > Author: rnk > > Date: Tue Feb 9 13:53:30 2016 > > New Revision: 260267 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=260267=rev > > Log: > > Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp > > > > This is the third time it has crossed the 2^16 section limit. We've > > already spent time optimizing this file to reduce template > > instantiations, and it's not clear that there is anymore low hanging > > fruit. > > Bummer. Do we have any mechanisms in place that will bark loudly at us > when we accidentally introduce a large quantity of symbols from this > file now? That has also happened a few times, and /bigobj warnings > were the primary way we were notified (since it's difficult to tell > from file size alone). > No, there isn't any mechanism. I think what we really should be worrying about is overall code size, and that this particular section count limit is arbitrary. If we tackled the code size problem directly, we'd use a tool to highlight code that has a high source-line-to-code-byte ratio. I know Chromium has done this in the past to identify overly inlined functions and things that shouldn't be templates. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260267 - Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp
Author: rnk Date: Tue Feb 9 13:53:30 2016 New Revision: 260267 URL: http://llvm.org/viewvc/llvm-project?rev=260267=rev Log: Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp This is the third time it has crossed the 2^16 section limit. We've already spent time optimizing this file to reduce template instantiations, and it's not clear that there is anymore low hanging fruit. Modified: cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt Modified: cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt?rev=260267=260266=260267=diff == --- cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt (original) +++ cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt Tue Feb 9 13:53:30 2016 @@ -1,5 +1,14 @@ set(LLVM_LINK_COMPONENTS support) +# The registry source file ends up generating a lot of sections for each +# matcher. Each matcher appears to get a vtable and several methods. Each +# method needs .text, .pdata, .xdata, and .debug sections, adding to the +# section multiplier. By default MSVC has a 2^16 limit on the number of +# sections in an object file, and this needs more than that. +if (MSVC) + set_source_files_properties(Registry.cpp PROPERTIES COMPILE_FLAGS /bigobj) +endif() + add_clang_library(clangDynamicASTMatchers Diagnostics.cpp VariantValue.cpp ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits