This is an archive of the discontinued LLVM Phabricator instance.

[CMake] -gen-dag-isel: add -omit-comments if neither Debug nor RelWithDebInfo
ClosedPublic

Authored by MaskRay on Apr 26 2020, 1:55 PM.

Details

Summary

Omitting comments can make the output much smaller. Size/time impact on
my machine:

  • lib/Target/AArch64/AArch64GenDAGISel.inc, 10MiB (8.89s) -> 5MiB (3.20s)
  • lib/Target/X86/X86GenDAGISel.inc, 20MiB (6.48s) -> 8.5MiB (4.18s)

In total, this change decreases lib/Target/*/*GenDAGISel.inc from
71.4MiB to 30.1MiB.

Diff Detail

Event Timeline

MaskRay created this revision.Apr 26 2020, 1:55 PM
thakis accepted this revision.May 7 2020, 4:04 PM

Nice find! Should we just disable them always unless someone explicitly asks for them?

Please wait with landing for nhaehnle to chime in.

This revision is now accepted and ready to land.May 7 2020, 4:04 PM

Nice find! Should we just disable them always unless someone explicitly asks for them?

Please wait with landing for nhaehnle to chime in.

Yeah, we can teach more TableGen backends to understand -omit-comments...

I guess comments are occasionally useful for some developers debugging code in generated code. If the build is a non-debug one, then certainly these comments are not needed...

rnk added inline comments.May 9 2020, 8:30 AM
llvm/cmake/modules/TableGen.cmake
59

IMO this condition is a bit awkward, but I can't suggest a better one. I think to be thorough we might want to raise this up to a cmake option next to LLVM_OPTIMIZED_TABLEGEN, but I won't insist on it.

I use a release build, and I appreciate comments in other table generated files, but I have never debugged DAG isel matchers.

This revision was automatically updated to reflect the committed changes.

I am very much opposed to this. I just wish I noticed it before it was approved and pushed. In my opinion, the debug dumps from the SDAG are the most useful and easiest to follow of all of the passes in LLVM. A release + asserts build is a very common way for people to build and without the comments in the .inc files, the debug dumps from the SDAG are useless.

I understand that this reduces the size of the produced code, but I don't think the cost is worth the benefit. Personally, I would not differentiate this from other things we get under #ifndef NDEBUG. If you don't want the comments, build with something that defines NDEBUG.
So I think a much better way to disable comments would be something like:

diff --git a/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp b/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp
index d9ec14a..99bc3e9 100644
--- a/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp
+++ b/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp
@@ -36,7 +36,12 @@ cl::OptionCategory DAGISelCat("Options for -gen-dag-isel");
 // To reduce generated source code size.
 static cl::opt<bool> OmitComments("omit-comments",
                                   cl::desc("Do not generate comments"),
-                                  cl::init(false), cl::cat(DAGISelCat));
+#ifndef NDEBUG
+                                  cl::init(false),
+#else
+                                  cl::init(true),
+#endif
+                                  cl::cat(DAGISelCat));
 
 static cl::opt<bool> InstrumentCoverage(
     "instrument-coverage",

I am very much opposed to this. I just wish I noticed it before it was approved and pushed. In my opinion, the debug dumps from the SDAG are the most useful and easiest to follow of all of the passes in LLVM. A release + asserts build is a very common way for people to build and without the comments in the .inc files, the debug dumps from the SDAG are useless.

I understand that this reduces the size of the produced code, but I don't think the cost is worth the benefit. Personally, I would not differentiate this from other things we get under #ifndef NDEBUG. If you don't want the comments, build with something that defines NDEBUG.
So I think a much better way to disable comments would be something like:

diff --git a/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp b/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp
index d9ec14a..99bc3e9 100644
--- a/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp
+++ b/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp
@@ -36,7 +36,12 @@ cl::OptionCategory DAGISelCat("Options for -gen-dag-isel");
 // To reduce generated source code size.
 static cl::opt<bool> OmitComments("omit-comments",
                                   cl::desc("Do not generate comments"),
-                                  cl::init(false), cl::cat(DAGISelCat));
+#ifndef NDEBUG
+                                  cl::init(false),
+#else
+                                  cl::init(true),
+#endif
+                                  cl::cat(DAGISelCat));
 
 static cl::opt<bool> InstrumentCoverage(
     "instrument-coverage",

How are comments helpful if no debugging information is produced (neither RelWithDebInfo nor Debug)? You don't have line tables and the debugger cannot associate the source lines. If you have reasons that -UNDEBUG builds may need comments, we can check LLVM_ENABLE_ASSERTIONS in CMake as well.

How are comments helpful if no debugging information is produced (neither RelWithDebInfo nor Debug)? You don't have line tables and the debugger cannot associate the source lines. If you have reasons that -UNDEBUG builds may need comments, we can check LLVM_ENABLE_ASSERTIONS in CMake as well.

The dump from -debug-only=isel lists everything the instruction selector tried in order which makes it very easy to reason about what it did. But the indices into the MatcherTable are the comments that this patch removes. The reason I suggested using NDEBUG is that the debug messages from the SDAG that refer to these are also guarded by that macro (since they are LLVM_DEBUG messages).