[llvm-dev] wasteful cmake defaults

Wed Nov 18 07:37:49 PST 2020


> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David
> Chisnall via llvm-dev
> Sent: Wednesday, November 18, 2020 6:32 AM
> To: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] wasteful cmake defaults
> 
> On 17/11/2020 18:25, Luke Drummond via llvm-dev wrote:
> >> -- 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://urldefense.com/v3/__https://github.com/llvm/llvm-
> project/blob/9218ff50f93085d0a16a974db28ca8f14bc66f64/llvm/CMakeLists.txt*
> L57-
> L60__;Iw!!JmoZiZGBv3RvKRSx!pbrEqQxC9HKXzCXnbVPOezybndBSk6GZShkECVJPUB7Pjax
> HX2noFrIRX8qXPuJ15Q$
> >
> > 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 think you are conflating two things somewhat here:
> 
>   - Is it useful to do an -O0 build without assertions or debug info?
>   - What is the most useful default build configuration?
> 
> These are somewhat separable.  As others have said, the first can be
> achieved by specifying a release build with -O0 in the CXXFLAGS.  This
> is honestly not something I've ever considered doing, because the extra
> time to run a handful of tests at -O0 is likely to offset any build-time
> improvements.  It's useful if you want to get an LLVM binary quickly,
> but not so useful if you want to actually run it.  If you run it and it
> doesn't work, then you'll still need to do a debug build to get useful
> debug information.  As such, I'm not sure that I understand the use case.
> 
> In terms of the most useful build configuration to be the default, I
> think there are a bunch of users that we need to consider:
> 
>   - Developers of LLVM
>   - Developers of downstream projects that use LLVM
>   - Package builders
>   - CI admins.
> 
> Some of these are easy.  CI admins are likely to want to configure their
> builds explicitly and so won't want to use the defaults.  Package
> builders are going to want a Release build, but generally put that in
> their configuration for the package file and so don't care too much what
> the default is.
> 
> Developers of LLVM and downstream projects are similar.  Downstream
> projects come in two flavours:
> 
>   - Ones that depend on an LLVM release version existing
>   - Ones that ship their own LLVM as a submodule.
> 
> The second is less of a problem because it will be driving the LLVM
> build from its own build infrastructure and so has a one-time cost for
> configuration and anyone building that project inherits the benefits.
> 
> The first is more of a problem because build configurations of LLVM
> change its ABI, so you need to match the LLVM build to the downstream
> project's build configuration.  This is generally fairly easy to do by
> just pointing at the llvm-config built by the specific LLVM output, so
> you can easily have Debug / Release / Whatever builds of your project
> using different llvm-config versions.  Supporting this means that you
> are already propagating config from LLVM and people building your
> project in anything other than a relase configuration need to do a
> non-default build of LLVM.
> 
> This leaves LLVM developers.  I'd assume that these are the people
> building LLVM manually the most often and so it makes sense to provide
> them with a default that makes sense.  Unfortunately, there isn't a
> single one that makes sense for developers.
> 
> For the last few years, I've been following Chandler's suggestion and
> building a Release + Asserts build and a Debug + ASan + expensive checks
> build whenever I work on LLVM.  Release with asserts is reasonably fast
> running the tests and fast to build, so a compile-test cycle is not too
> bad.  When that fails, I can switch to the other build and get something
> that's easy to debug.  I also generally try to run the entire test suite
> in this configuration once before merging to master because it picks up
> memory management bugs that may not actually break anything in the
> (simple) test cases.

My own personal default is Release + Asserts + -g1 (line tables only).
This gives tracebacks with source locations on a crash/assert, and is
noticeably faster to build than RelWithDebInfo (the main benefit to the
latter is symbolized tracebacks).  As a rule I find logging/printf to
work more effectively than a debugger so I don't usually miss having
debug info; I can always run a debug build if I have to.
--paulr

> 
> The default isn't for either of those.  I'd be quite happy for the
> default to be either Debug + ASan + expensive tests or Release +
> Asserts, but given that I have to manually configure one of them,
> there's limited value in needing less manual configuration for the other.
> 
> Perhaps the right solution is for the build to fail and tell people to
> pick one if they don't specify CMAKE_BUILD_TYPE.
> 
> David
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/llvm-
> dev__;!!JmoZiZGBv3RvKRSx!pbrEqQxC9HKXzCXnbVPOezybndBSk6GZShkECVJPUB7PjaxHX
> 2noFrIRX8qo20n0jA$