[llvm-dev] wasteful cmake defaults
Chris Tetreault via llvm-dev
llvm-dev at lists.llvm.org
Wed Nov 18 09:44:09 PST 2020
I have no strong opinion on this topic personally (I always set the build type to something if I’m not generating a Visual Studio project), but this “non-optimized, non-asserting, non-debug-info-containing” build that you get when not specifying the build type to CMake is a quirk that I feel most CMake users expect at this point. I don’t think there’s any real value in providing a useful default if nobody accepts the default anyways due to having been burned in the past.
Thanks,
Christopher Tetreault
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Mehdi AMINI via llvm-dev
Sent: Tuesday, November 17, 2020 7:16 PM
To: Luke Drummond <luke.drummond at codeplay.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] wasteful cmake defaults
Hi,
The CMake default is an empty build type, which yield a non-optimized build without debug information and without assertions, it isn't clear that it is really good for most (developers likely want debug info and assertions in non-optimized builds, non developers may want a release build).
See also the revision that introduced the current behavior: http://reviews.llvm.org/D7360
We could make Release the default I guess, the main drawback I see right now is that it could affect bots that are relying on the default and wouldn't get assertions anymore?
That said our upstream buildbots infra seems to have explicit defaults: https://github.com/llvm/llvm-zorg/blob/master/zorg/buildbot/builders/UnifiedTreeBuilder.py#L125-L127
For LLD, I don't think we have auto-detection, but I'd be on-board with auto-detecting it and have -DLLVM_ENABLE_LLD default to the auto-detection when empty. But that's another topic...
--
Mehdi
On Tue, Nov 17, 2020 at 5:50 PM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Yeah, that's one I'd be in favor of fixing, if it's still the case.
On Tue, Nov 17, 2020 at 5:38 PM Sean Silva via llvm-dev
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
>
> I'm curious how much of this is due to not using LLD? Last I checked, using ld.bfd instead of LLD (or gold) was one of my major build time issues, and somehow our default configuration would use ld.bfd.
>
> -- Sean Silva
>
> On Tue, Nov 17, 2020 at 10:25 AM Luke Drummond via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>> Hi all
>>
>> I wanted to do a quick build of a clean branch yesterday and noticed
>> something surprising in the configure log:
>>
>> > -- No build type selected, default to Debug
>>
>> It appears that llvm's configuration forces Debug builds if the user
>> does not specify the build type.
>>
>> https://github.com/llvm/llvm-project/blob/9218ff50f93085d0a16a974db28ca8f14bc66f64/llvm/CMakeLists.txt#L57-L60
>>
>> I've just done a build of llvm and clang 10 in debug mode for X86 and
>> ARM targets and it weighs in at a whopping 75GiB. I feel that forcing
>> Debug builds in the absence of an option to be a wasteful default. It is
>> a valid and useful thing to call cmake without specifying a build type;
>> absence of a command line switch does not always imply absence of a
>> choice.
>>
>> I took some measurements. The machine under test is an otherwise
>> unloaded Ryzen 2 server with 6 cores / 12 threads and fast NVME SSDs
>> running Debian sid with gcc-10.2 as the host toolchain.
>>
>> $ cmake ../llvm -DCMAKE_BUILD_TYPE=Debug -GNinja \
>> -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
>> ...
>> $ time ninja llc
>> ...
>> [1199/1199] Linking CXX executable bin/llc
>> ninja llc 6858.95s user 218.53s system 1095% cpu 10:45.78 total
>>
>> and then:
>>
>> $ git apply <<'EOF'
>> diff --git a/llvm/CMakeLists.txt b/llvm/CMakeLists.txt
>> index 21563e15118..3f5821351a1 100644
>> --- a/llvm/CMakeLists.txt
>> +++ b/llvm/CMakeLists.txt
>> @@ -55,8 +55,8 @@ set(CMAKE_CXX_STANDARD_REQUIRED YES)
>> set(CMAKE_CXX_EXTENSIONS NO)
>>
>> if (NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
>> - message(STATUS "No build type selected, default to Debug")
>> - set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Build type (default Debug)" FORCE)
>> + # message(STATUS "No build type selected, default to Debug")
>> + # set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Build type (default Debug)" FORCE)
>> endif()
>>
>> # Side-by-side subprojects layout: automatically set the
>> EOF
>>
>> $ cmake ../llvm -DCMAKE_BUILD_TYPE= -GNinja -DLLVM_TARGETS_TO_BUILD=X86 \
>> -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
>> ...
>> $ time ninja llc
>> [1199/1199] Linking CXX executable bin/llc
>> ninja llc 5714.52s user 159.31s system 1125% cpu 8:41.99 total
>>
>> There's two minutes difference just for an X86 capable `llc` target on
>> this machine. I imagine there are plenty of configurations in which the
>> ratio is *much* larger e.g. machines with slow disks and lots of cores.
>>
>> I think this speedup will be especially useful in CI systems where
>> getting a compiler build quickly is more important than getting a quick
>> compiler. I don't imagine we ever use the debuginfo generated by the
>> host toolchain in the buildbots, either.
>>
>> Is there anything I'm missing, or can this override be safely deleted?
>> Would a patch to Zorg be needed / appropriate for the fast buildbots?
>>
>> All the Best
>>
>> Luke
>>
>> --
>> Codeplay Software Ltd.
>> Company registered in England and Wales, number: 04567874
>> Registered office: Regent House, 316 Beulah Hill, London, SE19 3HF
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201118/a7363064/attachment.html>
More information about the llvm-dev
mailing list