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

[Óscar Fuentes]

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.

One step more is not a lot of work, IMO, and the patch adds too much
complexity for the value of the feature it implements (again IMO).

But there is another possibility. The current build already supports
building and using an external tblgen in Release mode. That was
implemented to be used while cross-compiling, but a quick look makes me
think that adapting it to your scenario would require just a few
lines. It was created with makefile generators in mind, so it must be
adapted to use with VS, which looks quite easy (if you build with the VS
IDE or msbuild.exe (i.e. MSVC_IDE is true) tblgen.exe ends on
bin/Release directory) Look for

if( CMAKE_CROSSCOMPILING )

on the toplevel CMakeLists.txt and follow from there.

[snip]

>> IIRC you can build two libraries with the same source files from the same
>> CMakeLists.txt:
>>
>> set(SOURCES
>>   APFloat.cpp
>>   <rest of source files>
>>   )
>>
>> add_llvm_library(LLVMSupport ${SOURCES})
>>
>> if( LLVM_ALWAYS_OPTIMIZE_UTILS )
>>   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.

Good to know. I've just asked on the cmake ml about the absence on
CXX_FLAGS_RELEASE and similar target features.

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

[snip]

>> 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?

Yes, it is harmless. But let's leave this aside for now and concentrate
on using the externaly built tblgen executable, as described above.