Re: r260267 - Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp

2016-02-09 Thread Aaron Ballman via cfe-commits
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).

~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

2016-02-09 Thread Aaron Ballman via cfe-commits
On Tue, Feb 9, 2016 at 3:59 PM, Reid Kleckner  wrote:
> 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

2016-02-09 Thread Reid Kleckner via cfe-commits
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.

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

2016-02-09 Thread Reid Kleckner via cfe-commits
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