[llvm-dev] wasteful cmake defaults
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Fri Nov 20 11:23:00 PST 2020
I'll comment that not all new developers of LLVM have experience
w/cmake. A while back, we did a hack-a-thon for folks interested in
learning about LLVM. We had many, many, many new contributors who lost
most of the day to build times and build sizes because of the defaults.
(The size issue was almost the bigger problem; many didn't have enough
free space to complete a unoptimized/debug build.)
Personally, I think we should either a) change the defaults or b) put a
prominent warning in the docs.
Philip
On 11/18/2020 9:44 AM, Chris Tetreault via llvm-dev wrote:
>
> 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 <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
> <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
> <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
> <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
> <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
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
> _______________________________________________
> LLVM Developers mailing list
> 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/20201120/067e0760/attachment.html>
More information about the llvm-dev
mailing list