[llvm-commits] [PATCH] CMake option for enabling optimization for utilities in debug build

Erik Olofsson Erik.Olofsson at hansoft.se
Sun Mar 13 16:23:01 PDT 2011

> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> Subject: Re: [llvm-commits] [PATCH] CMake option for enabling
> optimization for utilities in debug build
> Erik Olofsson <Erik.Olofsson at hansoft.se>
> writes:
> > This patch enables optimization for the utilities such as tblgen in
> > the utils dir in Debug builds. This decreases the compile time of the
> > debug build considerably on Visual Studio, and somewhat on OSX.
> There is one way of using an optimized tlbgen executable: configure setting
> LLVM_TABLEGEN. You can point it to a tblgen.exe that still does not exist.
> Supposing that you are using VS and your build directory is c:\build :
> cmake -DLLVM_TABLEGEN=c:/build/bin/Release/tblgen.exe
> path/to/llvm/sources
> Now we build the tblgen target in Release mode. You can do that from the
> IDE but with the command line is:
> cmake --build . --target tblgen --config Release
> Now you can build in Debug mode. The tblgen.exe generated above will be
> used:
> cmake --build . --config Debug

Yes, I suspected as much, but it's a lot of manual work each time you need to do it.

> Zi ? Why? Is it because the linker complains? Then, you should set the flags
> for linking too.

No it works without. Even though you optimize the executable it is still the Debug build so symbols are nice. Could change to CMAKE_CXX_FLAGS_RELWITHDEBUGINFO so you get this, but this build has less optimizations.

> IIRC you can build two libraries with the same source files from the same
> CMakeLists.txt:
>   APFloat.cpp
>   <rest of source files>
>   )
> add_llvm_library(LLVMSupport ${SOURCES})
>   add_llvm_library(OptimizedLLVMSupport ${SOURCES})
>   <set compiler options for target OptimizedLLVMSupport>
> endif()
> [snip]

I tried this approach first, but the problem is that you can only set COMPILE_FLAGS for all build types at once. CMAKE_CXX_FLAGS_DEBUG is applied first and you end up with /RTC1 /O2 which are incompatible. The solution to this is to remove /RTC1 from CMAKE_CXX_FLAGS_DEBUG but that affects everything, or if you do it in one directory you might as well use the approach I use now.

CMAKE_CXX_FLAGS_xxx can be changed per directory, but not changed inside one CMakeList.txt several times (last set will apply to all targets), that is why I put the library into its own directory.

I guess I could apply the prefix to the list of sources in a more elegant way though...

> > Index: utils/TableGen/CMakeLists.txt
> >
> ===================================================================
> > --- utils/TableGen/CMakeLists.txt     (revision 127564)
> > +++ utils/TableGen/CMakeLists.txt     (working copy)
> > @@ -3,6 +3,8 @@
> >
> >
> > +fix_utils_compile_options()
> > +
> >  add_llvm_utility(tblgen
> >    ARMDecoderEmitter.cpp
> >    AsmMatcherEmitter.cpp
> > @@ -45,7 +47,7 @@
> >    X86RecognizableInstr.cpp
> >    )
> >
> > -target_link_libraries(tblgen LLVMSupport)
> > +target_link_libraries(tblgen ${LLVM_UTILS_SUPPORT_LIB_NAME})
> >  if( MINGW )
> >    target_link_libraries(tblgen imagehlp psapi)  endif( MINGW )
> I think that all those changes to the utils/*/CMakeLists.txt files will be
> unnecessary if you take advantage of the existence of add_llvm_utility
> (defined in $LLVM_SOURCE_ROOT/cmake/modules/AddLLVM.cmake). It
> would make fix_utils_compile_options unnecessary too.

Yes I should be able to call fix_utils_compile_options from add_llvm_utility. LLVM_UTILS_SUPPORT_LIB_NAME could be added in add_llvm_utility, but the count utility doesn't use LLVMSupport. Should add_llvm_utility  take an option to add LLVMSupport or is it harmless to add that dependency to count?


More information about the llvm-commits mailing list