For -Rpass, and other related uses, I am looking at enabling column info by default. David pointed me at PR 14106, which seems to be the original motivation for introducing -gcolumn-info. However, I am finding no differences when using it on this test. I've tried building with/without -gcolumn-info and found almost no difference in compile time (+0.4%): $ /usr/bin/time clang -w -fno-builtin -O2 -g -gcolumn-info test-tgmath2.i 474.38user 2.10system 7:58.00elapsed 99%CPU $ /usr/bin/time clang -w -fno-builtin -O2 -g test-tgmath2.i 472.63user 2.02system 7:56.11elapsed 99%CPU I'm running clang from trunk @211693. The size of all debug sections (according to readelf) are: - with -g -gcolumn-info: 836,177 bytes - with -g: 826,552 bytes That's a growth of about 1% in debug info size. These numbers are in line with a comparative build I did of our internal codebase. The build included a massive number of C and C++ files. For C files, total file size grows by 1% on average. For C++ files the average growth is around 0.2%. Build times are unchanged as well. Does anyone remember any other edge case I may want to try? It seems to me that these differences are not really worth the effort of having a flag controlling column information. Thanks. Diego. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140626/72251654/attachment.html>
On Thu, Jun 26, 2014 at 9:46 AM, Diego Novillo <dnovillo at google.com> wrote:> For -Rpass, and other related uses, I am looking at enabling column info by > default. David pointed me at PR 14106, which seems to be the original > motivation for introducing -gcolumn-info. However, I am finding no > differences when using it on this test. I've tried building with/without > -gcolumn-info and found almost no difference in compile time (+0.4%): > > $ /usr/bin/time clang -w -fno-builtin -O2 -g -gcolumn-info test-tgmath2.i > 474.38user 2.10system 7:58.00elapsed 99%CPU > > $ /usr/bin/time clang -w -fno-builtin -O2 -g test-tgmath2.i > 472.63user 2.02system 7:56.11elapsed 99%CPU > > I'm running clang from trunk @211693. > > The size of all debug sections (according to readelf) are: > > - with -g -gcolumn-info: 836,177 bytes > - with -g: 826,552 bytes > > That's a growth of about 1% in debug info size. > > These numbers are in line with a comparative build I did of our internal > codebase. The build included a massive number of C and C++ files. For C > files, total file size grows by 1% on average. For C++ files the average > growth is around 0.2%. Build times are unchanged as well. > > Does anyone remember any other edge case I may want to try? It seems to me > that these differences are not really worth the effort of having a flag > controlling column information. >I remember it being larger last I'd looked, but I know I didn't have quite the range that you just tested. I'm all for turning it on - especially if it doesn't really cost us anything. Adrian: any issues on your end before I turn it on by default and remove the option? This will also obviate a few of the patches that you had to distinguish call sites as well I think. -eric
The main motivation for turning it off is that no known consumer (debugger) took advantage of it. Turning it on does more than slightly increase the object file size, it can cause the same source line to be listed multiple times in the .debug_line table (with different column numbers). This can be confusing to debuggers that ignore column info, or possibly to the users who expect “set breakpoint on line 12” to set one breakpoint and it actually sets 4. “How come nothing happens when I hit Continue?” Or it can affect single-stepping, which might stop at the next “is-statement” entry, even if the line hasn’t changed. “How come I have to hit Step 4 times to get it to go to the next line?” For –Rpass and related uses, it might be useful to distinguish between _tracking_ column numbers and _emitting_ column numbers. IIUC –Rpass wants column info tracked during compilation so it can show the things it wants to show with maximum relevance. Whether those column numbers actually make it into the .debug_line section is a different story. --paulr From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Diego Novillo Sent: Thursday, June 26, 2014 9:46 AM To: LLVM Developers Mailing List; Eric Christopher; David Blaikie; octoploid at yandex.com; craig.topper at gmail.com; Chris Lattner Subject: [LLVMdev] -gcolumn-info and PR 14106 For -Rpass, and other related uses, I am looking at enabling column info by default. David pointed me at PR 14106, which seems to be the original motivation for introducing -gcolumn-info. However, I am finding no differences when using it on this test. I've tried building with/without -gcolumn-info and found almost no difference in compile time (+0.4%): $ /usr/bin/time clang -w -fno-builtin -O2 -g -gcolumn-info test-tgmath2.i 474.38user 2.10system 7:58.00elapsed 99%CPU $ /usr/bin/time clang -w -fno-builtin -O2 -g test-tgmath2.i 472.63user 2.02system 7:56.11elapsed 99%CPU I'm running clang from trunk @211693. The size of all debug sections (according to readelf) are: - with -g -gcolumn-info: 836,177 bytes - with -g: 826,552 bytes That's a growth of about 1% in debug info size. These numbers are in line with a comparative build I did of our internal codebase. The build included a massive number of C and C++ files. For C files, total file size grows by 1% on average. For C++ files the average growth is around 0.2%. Build times are unchanged as well. Does anyone remember any other edge case I may want to try? It seems to me that these differences are not really worth the effort of having a flag controlling column information. Thanks. Diego. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140626/a15670b0/attachment.html>
> On Jun 26, 2014, at 12:31 PM, Eric Christopher <echristo at gmail.com> wrote: > > On Thu, Jun 26, 2014 at 9:46 AM, Diego Novillo <dnovillo at google.com> wrote: >> For -Rpass, and other related uses, I am looking at enabling column info by >> default. David pointed me at PR 14106, which seems to be the original >> motivation for introducing -gcolumn-info. However, I am finding no >> differences when using it on this test. I've tried building with/without >> -gcolumn-info and found almost no difference in compile time (+0.4%): >> >> $ /usr/bin/time clang -w -fno-builtin -O2 -g -gcolumn-info test-tgmath2.i >> 474.38user 2.10system 7:58.00elapsed 99%CPU >> >> $ /usr/bin/time clang -w -fno-builtin -O2 -g test-tgmath2.i >> 472.63user 2.02system 7:56.11elapsed 99%CPU >> >> I'm running clang from trunk @211693. >> >> The size of all debug sections (according to readelf) are: >> >> - with -g -gcolumn-info: 836,177 bytes >> - with -g: 826,552 bytes >> >> That's a growth of about 1% in debug info size. >> >> These numbers are in line with a comparative build I did of our internal >> codebase. The build included a massive number of C and C++ files. For C >> files, total file size grows by 1% on average. For C++ files the average >> growth is around 0.2%. Build times are unchanged as well. >> >> Does anyone remember any other edge case I may want to try? It seems to me >> that these differences are not really worth the effort of having a flag >> controlling column information. >> > > I remember it being larger last I'd looked, but I know I didn't have > quite the range that you just tested. I'm all for turning it on - > especially if it doesn't really cost us anything. > > Adrian: any issues on your end before I turn it on by default and > remove the option? This will also obviate a few of the patches that > you had to distinguish call sites as well I think.No, please do! I’ve been wanting to enable it by default for a long time. We can also get rid of all uses of forceColumnInfo this way. -- adrian> > -eric
On Thu, Jun 26, 2014 at 12:39 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:> The main motivation for turning it off is that no known consumer (debugger) > took advantage of it. >There are lots of non-debugger consumers of debug info, and now we've got cases where we actively want it for those.> Turning it on does more than slightly increase the object file size, it can > cause the same source line to be listed multiple times in the .debug_line > table (with different column numbers). This can be confusing to debuggers > that ignore column info, or possibly to the users who expect “set breakpoint > on line 12” to set one breakpoint and it actually sets 4. “How come nothing > happens when I hit Continue?” >Honestly IMO this is a "please fix your debugger, it has bugs" issue. -eric> Or it can affect single-stepping, which might stop at the next > “is-statement” entry, even if the line hasn’t changed. “How come I have to > hit Step 4 times to get it to go to the next line?” > > > > For –Rpass and related uses, it might be useful to distinguish between > _tracking_ column numbers and _emitting_ column numbers. IIUC –Rpass wants > column info tracked during compilation so it can show the things it wants to > show with maximum relevance. Whether those column numbers actually make it > into the .debug_line section is a different story. > > --paulr > > > > > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Diego Novillo > Sent: Thursday, June 26, 2014 9:46 AM > To: LLVM Developers Mailing List; Eric Christopher; David Blaikie; > octoploid at yandex.com; craig.topper at gmail.com; Chris Lattner > Subject: [LLVMdev] -gcolumn-info and PR 14106 > > > > For -Rpass, and other related uses, I am looking at enabling column info by > default. David pointed me at PR 14106, which seems to be the original > motivation for introducing -gcolumn-info. However, I am finding no > differences when using it on this test. I've tried building with/without > -gcolumn-info and found almost no difference in compile time (+0.4%): > > > > $ /usr/bin/time clang -w -fno-builtin -O2 -g -gcolumn-info test-tgmath2.i > > 474.38user 2.10system 7:58.00elapsed 99%CPU > > > > $ /usr/bin/time clang -w -fno-builtin -O2 -g test-tgmath2.i > > 472.63user 2.02system 7:56.11elapsed 99%CPU > > > > I'm running clang from trunk @211693. > > > > The size of all debug sections (according to readelf) are: > > > > - with -g -gcolumn-info: 836,177 bytes > > - with -g: 826,552 bytes > > > > That's a growth of about 1% in debug info size. > > > > These numbers are in line with a comparative build I did of our internal > codebase. The build included a massive number of C and C++ files. For C > files, total file size grows by 1% on average. For C++ files the average > growth is around 0.2%. Build times are unchanged as well. > > > > Does anyone remember any other edge case I may want to try? It seems to me > that these differences are not really worth the effort of having a flag > controlling column information. > > > > > > Thanks. Diego.
On Thu, Jun 26, 2014 at 3:39 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:> The main motivation for turning it off is that no known consumer (debugger) > took advantage of it. > > Turning it on does more than slightly increase the object file size, it can > cause the same source line to be listed multiple times in the .debug_line > table (with different column numbers). This can be confusing to debuggers > that ignore column info, or possibly to the users who expect “set breakpoint > on line 12” to set one breakpoint and it actually sets 4. “How come nothing > happens when I hit Continue?”Yes. David is testing the gdb testsuite to see whether that's a real problem. If that's a problem, it should show there (since GCC does not emit column info in dwarf, AFAIR). In any case, that would be a debugger issue. Not compiler.> For –Rpass and related uses, it might be useful to distinguish between > _tracking_ column numbers and _emitting_ column numbers. IIUC –Rpass wants > column info tracked during compilation so it can show the things it wants to > show with maximum relevance. Whether those column numbers actually make it > into the .debug_line section is a different story.That's already done. -Rpass now enables a special loc tracking mode that causes no dwarf generation. The issue is the combination of -Rpass -g. With -Rpass alone, turning on column info is fine (since no debug output will be generated). However, -Rpass -g would be penalized since no column info would be shown in that case. Diego.
On Thu, Jun 26, 2014 at 9:46 AM, Diego Novillo <dnovillo at google.com> wrote:> For -Rpass, and other related uses, I am looking at enabling column info > by default. David pointed me at PR 14106, which seems to be the original > motivation for introducing -gcolumn-info. However, I am finding no > differences when using it on this test. I've tried building with/without > -gcolumn-info and found almost no difference in compile time (+0.4%): > > $ /usr/bin/time clang -w -fno-builtin -O2 -g -gcolumn-info test-tgmath2.i > > 474.38user 2.10system 7:58.00elapsed 99%CPU > > $ /usr/bin/time clang -w -fno-builtin -O2 -g test-tgmath2.i > 472.63user 2.02system 7:56.11elapsed 99%CPU > > I'm running clang from trunk @211693. > > The size of all debug sections (according to readelf) are: > > - with -g -gcolumn-info: 836,177 bytes > - with -g: 826,552 bytes > > That's a growth of about 1% in debug info size. >What about the difference between -gmlt and -gmlt + -gcolumn-info?> > These numbers are in line with a comparative build I did of our internal > codebase. The build included a massive number of C and C++ files. For C > files, total file size grows by 1% on average. For C++ files the average > growth is around 0.2%. Build times are unchanged as well. > > Does anyone remember any other edge case I may want to try? It seems to me > that these differences are not really worth the effort of having a flag > controlling column information. > > > Thanks. Diego. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Alexey Samsonov vonosmas at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140701/6f68cb2d/attachment.html>
On Tue, Jul 1, 2014 at 7:56 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:> > On Thu, Jun 26, 2014 at 9:46 AM, Diego Novillo <dnovillo at google.com> wrote: >> >> For -Rpass, and other related uses, I am looking at enabling column info >> by default. David pointed me at PR 14106, which seems to be the original >> motivation for introducing -gcolumn-info. However, I am finding no >> differences when using it on this test. I've tried building with/without >> -gcolumn-info and found almost no difference in compile time (+0.4%): >> >> $ /usr/bin/time clang -w -fno-builtin -O2 -g -gcolumn-info test-tgmath2.i >> 474.38user 2.10system 7:58.00elapsed 99%CPU >> >> $ /usr/bin/time clang -w -fno-builtin -O2 -g test-tgmath2.i >> 472.63user 2.02system 7:56.11elapsed 99%CPU >> >> I'm running clang from trunk @211693. >> >> The size of all debug sections (according to readelf) are: >> >> - with -g -gcolumn-info: 836,177 bytes >> - with -g: 826,552 bytes >> >> That's a growth of about 1% in debug info size. > > > What about the difference between -gmlt and -gmlt + -gcolumn-info?Debug info growth is larger in proportion (3%). Total binary size is roughly the same (~1%). Compile times are identical (7m47s for both). - with -gmlt -gcolumn-info: 319,792 bytes - with -gmlt: 310,243 bytes Diego.