User account creation filtered due to spam.

Bug 24729 - function calls created by builtins do not make use of inline definitions
Summary: function calls created by builtins do not make use of inline definitions
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.1.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on: 25022
  Show dependency treegraph
Reported: 2005-11-08 03:43 UTC by Kaveh Ghazi
Modified: 2006-04-30 13:35 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2005-11-24 17:03:24


Note You need to log in before you can comment on or make changes to this bug.
Description Kaveh Ghazi 2005-11-08 03:43:13 UTC
When doing transformations on builtins, if the builtin results in a function call that has an inline expansion, GCC emits a library call not the inline function body.  E.g. glibc defines an inline for fputc_unlocked.  Given this code:

#define _GNU_SOURCE
#include <stdio.h>
#define MAX 100000000

int main ()
  int i;
  for (i=0; i<MAX; i++)
    fputc_unlocked('1', stdout);
    fputs_unlocked("1", stdout);
  return 0;

If you compile it on a glibc box (I used x86_64-unknown-linux-gnu) with -O2 and look at the assembly the fputs_unlocked gets turned into fputc_unlocked as expected due to a strlen of 1 in the parameter, but nothing is further optimized.  However if you use -DFPUTC_DIRECT, you should see that GCC inserts the inline definition of fputc_unlocked and this version of the code runs about 10x faster than the library call to fputc_unlocked.

When expanding function calls created by builtin substitution, GCC should check if that identifier refers to an inline function and substitute that definition if possible.
Comment 1 Andrew Pinski 2005-11-08 03:52:50 UTC
I want to say this is dup of bug 17402 which was marked as will not fix.
Comment 2 Kaveh Ghazi 2005-11-08 04:28:23 UTC
I'm not convinced it's the same issue.  With regard to 17402, comment #6 by Joseph there refers specifically to static inlines in that builtins shouldn't generate calls to "file-scope statics".  However in my case glibc is instantiating *extern inlines* and it seems legitimate that gcc could (should) generate calls which take advantage of them.  (Plus they're much much faster!)

Comment 3 Richard Biener 2005-11-08 10:16:31 UTC
Note that it is too late for the inliner to come in at builtin expansion time.  It may be possible to "fix" this with the SSA inliner on IPA branch, but I'm not sure if it is worth it.  Maybe Honza can give some input?
Comment 4 Kaveh Ghazi 2005-11-14 01:00:18 UTC
Builtin fputs{_unlocked} et al. are transformed via fold_builtin as well as expand.  AFAICT folding is done rather early, so perhaps this can be fixed.
Comment 5 Kaveh Ghazi 2005-11-24 17:03:24 UTC
Here's a version of the testcase that doesn't rely on _unlocked functions since 25022 inhibits the unlocked transformations.  Compile at -O2 with and without -DPUTCHAR_DIRECT to see the effect.  Using putchar directly makes use of the extern inline and transforms into _IO_putc, whereas the printf call only gets as far as turning into putchar.

#include <stdio.h>
#undef putchar

int main ()
  printf ("\n");
  return 0;
Comment 6 Jan Hubicka 2006-04-30 13:33:31 UTC
This is probably won't fix as well.  The problem is that calls to builtins in general can be produced arbitrarily late in the compilation process (before RTL expansion).
We might try to do limited inliner pass specializing to extern inlines late in compilation but at the moment this is undoable because at that moment we are in SSA and having extern inlines released from memory.
On IPA branch we can get further but with all the aliasing datastructures built plus the fact that extern inline builtins might in general have totally inexpected behaviour, I think it is rather dangerous to implement.
Comment 7 Jan Hubicka 2006-04-30 13:35:57 UTC
I should probably also note that IPA branch will get it right in the testcase (and the other PR) via early inlining, but it sadly won't get it right in any consistent manner...