bug-gperf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gperf] Re: [PATCH] Use always_inline attribute with gcc


From: Bruno Haible
Subject: [bug-gperf] Re: [PATCH] Use always_inline attribute with gcc
Date: Wed, 19 May 2010 10:59:47 +0200
User-agent: KMail/1.9.9

Lucas De Marchi wrote:
> I was searching for a proper solution to a bug in webkit
> (https://bugs.webkit.org/show_bug.cgi?id=29244) and found this thread
> in gperf (http://lists.gnu.org/archive/html/bug-gperf/2009-09/msg00002.html).
> 
> As you can see it's an old bug that it's not solved yet. It's not that
> easy to fix it in WebKit and I'm wondering if the fix shouldn't go to
> gperf instead. I wouldn't like to have those functions in webkit not
> inlined when compiled with -O0. Changing the function attribute in
> gperf to __always_inline__ does solve the problem.
> ---
> This guarantees the code will be inlined even when no optimizations were
> chosen. Prior behavior was not to inline when -O0 was passed or when
> compiling with -fno-inline.
> ---
>  src/output.cc |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/src/output.cc b/src/output.cc
> index 4b0e4c6..65e9def 100644
> --- a/src/output.cc
> +++ b/src/output.cc
> @@ -1895,7 +1895,7 @@ Output::output_lookup_function () const
>      printf ("#ifdef __GNUC__\n"
>              "__inline\n"
>              "#if defined __GNUC_STDC_INLINE__ || defined 
> __GNUC_GNU_INLINE__\n"
> -            "__attribute__ ((__gnu_inline__))\n"
> +            "__attribute__ ((__always_inline__))\n"
>              "#endif\n"
>              "#endif\n");

I will certainly not apply a patch like this.
  1) You have not provided an explanation and analysis of the problem that
     WebKit is facing. In <https://bugs.webkit.org/show_bug.cgi?id=29244>
     12 persons participated in the discussion, and no one analyzed the
     problems. Your team needs to look at "nm" results, GCC versions,
     gcc command lines etc. more closely, read the GCC manual, and not
     just try this and that blindly without understanding the problem.
  2) If you have a problem that you mean to fix with __always_inline__,
     it is quite likely that your code will break with other compilers
     than GCC, which don't have __always_inline__. The only reasonable
     uses of __always_inline__ that I know of are
       - with inline asms,
       - when you play tricks with alloca,
       - when you write low-latency device drivers.
  3) __always_inline__ hampers debuggability. When line numbers are not
     correct even with -O0 -g, people will swear.

Bruno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]