[Mesa-dev] [PATCH] mesa: Enable LTO by default on i965/libdricore release builds.

Chad Versace chad.versace at linux.intel.com
Mon Aug 12 14:05:27 PDT 2013


On 08/08/2013 01:43 PM, Eric Anholt wrote:
> We can't just smash it on globally due to (probably resolvable) issues
> with the asm in glapi.  And we don't want to penalize developers with
> longer build times for their normal debug environment.
>
> Due to libdricore making almost all of our symbols public, the effect is
> very small -- cairo-gl with INTEL_NO_HW=1 shows -0.798709% +/- 0.333703%
> change in runtime (n=30).
> ---
>
> If we were to avoid dricore, there's an additional 5% improvement available
> (see the "megadriver" branch of my tree).
>
>   configure.ac                          | 25 +++++++++++++++++++++++++
>   src/mesa/Makefile.am                  |  4 ++--
>   src/mesa/drivers/dri/i965/Makefile.am |  1 +
>   src/mesa/libdricore/Makefile.am       |  8 +++++++-
>   src/mesa/program/Makefile.am          |  4 ++--
>   5 files changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 62d06e0..26c230d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -314,6 +314,7 @@ AC_ARG_ENABLE([debug],
>       [enable_debug="$enableval"],
>       [enable_debug=no]
>   )
> +enable_lto=yes
>   if test "x$enable_debug" = xyes; then
>       DEFINES_FOR_BUILD="$DEFINES_FOR_BUILD -DDEBUG"
>       if test "x$GCC_FOR_BUILD" = xyes; then
> @@ -330,7 +331,31 @@ if test "x$enable_debug" = xyes; then
>       if test "x$GXX" = xyes; then
>           CXXFLAGS="$CXXFLAGS -g -O0"
>       fi
> +
> +    # Disable LTO by default on debug builds, since it's so expensive at
> +    # compile time.
> +    enable_lto=no
> +fi

I'd like to emit a configuration error if someone tries to enable LTO
in a debug build. According the gcc-4.8 manpage, that's a really bad
idea.

            Link-time optimization does not work well with generation of
            debugging information.  Combining -flto with -g is currently
            experimental and expected to produce wrong results.

Other than that, the patch looks good to me.



More information about the mesa-dev mailing list