Disable debug, enable optimizations in build.sh script

[mborgerson]

Currently the build.sh script is set up for building a version of xqemu that can be more conveniently debugged (this script originates from my dev machine during rebase work). Since this is not the typical use case for xqemu, we should remove the debugging features and enable optimization. Perhaps we should add a --debug/--release option to the build script to make building a little easier. CI systems should build both optimized and debuggable versions to catch compilation issues in either case.

[JayFoxRox]

CI systems should build both optimized and debuggable versions to catch compilation issues in either case.

In my opinion we should not do this. That's be compiler bugs and we shouldn't have to worry about those. CI builds are for testing in nature, so they should probably be debug builds, with the exception of some release/final builds (which we should start providing soon).

I agree about supporting --debug / --release command line options though (just that we don't have to test / deploy both of them for every release).

[mborgerson]

In my opinion we should not do this. That's be compiler bugs and we shouldn't have to worry about those. CI builds are for testing in nature, so they should probably be debug builds, with the exception of some release/final builds (which we should start providing soon).

I was not really suggesting we hunt for compiler bugs when I suggested building both debug/release, what I had in mind was:

• Debug builds and release builds can (and often do) contain different code. Consider simply #if DEBUG code. With debug blocks like this, it's pretty common for release builds or debug builds fail, depending on what mode the developer was writing code in when they committed and created the PR. Maybe a variable definition was left in a DEBUG block and used outside. Maybe variables defined for debug builds are unused in release builds. These would cause compilation failures.
• Most people will want to download and run release builds for performance reasons. They may also want to use debug builds to help us track down issues. We can easily distribute both through the CI systems.
• It doesn't really cost us anything but PR/merge build time to do both builds in the CI systems. This is a perfect application of the matrix features of CI config scripts.

[illwieckz]

@mborgerson what would be the optimization options to pass to configure?

[mborgerson]

what would be the optimization options to pass to configure? - @illwieckz

Basically for debug builds:

• Keep --enable-debug config item
• Keep -O0 -g in CFLAGS

For release builds:

• Do not use --enable-debug config item
• Do not use -O0 -g in CFLAGS but instead probably -O3

[GXTX]

Wouldn't you want something like -O3 or -Ofast for release - and for debug something like -Og?

[MayeulC]

Keep in mind that in the past (that probably improved, but is still somewhat valid) compiling with -03:

• offered little gains over -02
• came at a greater memory and compilation time cost, in the lines of:
  • 10 minutes -> 5 hours
  • 200 MB -> 16 GB

That has to be benchmarked for xqemu, of course.
If you want some easy compile-time gains, I'd suggest toying around LTO (-flto) and PGO. But the added complexity of PGO releases mean that it might be better to keep that for point releases.