[Bug tree-optimization/34563] New: noinline function being inlined

[Bug tree-optimization/34563] New: noinline function being inlined

[hp at gcc dot gnu dot org]

With -O2, the function ii, called from function m in the attached file, is
inlined, despite the noinline attribute. There is an outlined ii emitted, but
no call to it in function m.  The code is an failed attempt to synthesize a
test-case for another bug (though for the record the failure isn't just because
of the inlining). Not being able to trivially stop inlining for otherwise
trivial calls is troublesome in this case, while possibly a mere wart for real
code.


-- 
           Summary: noinline function being inlined
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu, cris-axis-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563

[Bug tree-optimization/34563] noinline function being inlined

[hp at gcc dot gnu dot org]

------- Comment #1 from hp at gcc dot gnu dot org  2007-12-23 04:04 -------
Created an attachment (id=14808)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14808&action=view)
Compile with -O2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563

[Bug tree-optimization/34563] noinline function being inlined

[hp at gcc dot gnu dot org]

------- Comment #2 from hp at gcc dot gnu dot org  2007-12-23 04:05 -------
Revisions 130556 for native and 131139 for cris-elf.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563

[Bug tree-optimization/34563] noinline function call being removed

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2007-12-23 04:18 -------
So we have:
 if (ii (_double_.fp))
   ss = 0;
 cvt (_double_.fp, &ss);

ss is always set via cvt (and cvt is inlined), so we dce the first setting of
ss and that in turns dce the function call to ii as it is pure.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|noinline function being     |noinline function call being
                   |inlined                     |removed


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563

[Bug tree-optimization/34563] noinline function call being removed

[jkenisto at us dot ibm dot com]

------- Comment #7 from jkenisto at us dot ibm dot com  2008-01-09 22:35 -------
Testing of stuff like kprobes in Linux would be a lot easier if nolinline
worked reliably.  See this thread, for example:
http://marc.info/?l=linux-kernel&m=119991179332571&w=2

BTW, this sort of noinline failure can be demonstrated quite easily on my
system (i386 gcc v4.1.2) by compiling the following code with "gcc -S -O2":
-----
#define noinline __attribute__((noinline))
static noinline void plz_dont_inline_me(void)
{
}

void doit(void)
{
        plz_dont_inline_me();
}
-----

$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563

[Bug tree-optimization/34563] noinline function call being removed

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2008-01-09 22:45 -------
(In reply to comment #7)
> Testing of stuff like kprobes in Linux would be a lot easier if nolinline
> worked reliably.  See this thread, for example:
> http://marc.info/?l=linux-kernel&m=119991179332571&w=2

This function is not being inlined, the call to it is just being removed as the
function is const in this case. As shown by the change there, you are changing
a pure/const function into a function which is neither anymore so we don't
remove calls to functions which are neither pure or const as that would cause
wrong code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563

[Bug tree-optimization/34563] noinline function call being removed

[jkenisto at us dot ibm dot com]

------- Comment #9 from jkenisto at us dot ibm dot com  2008-01-17 18:52 -------
(In reply to comment #8)
> (In reply to comment #7)
> > Testing of stuff like kprobes in Linux would be a lot easier if nolinline
> > worked reliably.  See this thread, for example:
> > http://marc.info/?l=linux-kernel&m=119991179332571&w=2
> 
> This function is not being inlined, the call to it is just being removed as the
> function is const in this case. ...

It seems to me that omitting the call to the function and instead executing the
function's code (in this case, nothing) in the caller is the very essence of
inlining.  But let's not quibble about that.  The gcc manual doesn't address
this distinction, as far as I can tell.

Here's my concern.  For certain types of kprobes tests, we insert a kprobe
(essentially a non-interactive breakpoint) at the entry to a function* and then
verify that the number of probe hits matches the number of calls to the
function.  The probed function doesn't have to do anything but get called and
return, so an empty function is ideal.  If the function never gets called, the
test is useless.  gcc emitting an out-of-line copy that doesn't get called is
no help.  (*Because of the availability of symbol information and the
differences in code generation between compiler versions and between
architectures, function entry points are by far the most easily specified
probepoints.)

Since this topic came up, I've seen various suggestions for how to guarantee
that a function gets inlined -- e.g., make it a varargs function, or include an
empty asm statement.  The obvious danger there (aside from the apparent lack of
clarity as to what constitutes inlining) is that such guarantees are not
explicit and so may go away the next time gcc developers get ambitious about
inlining.

Also -- while I'm asking :-) -- I'd prefer the issue be addressed in a language
construct (e.g., the noinline attribute) rather than a command-line option
because it's tricky to build kprobes test modules with different options from
the rest of the kernel build.

FWIW, specifying noinline for an empty function used to work for me,  but that
was an older version of gcc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563

[Bug tree-optimization/34563] noinline function call being removed

[fche at redhat dot com]

------- Comment #10 from fche at redhat dot com  2008-01-17 21:04 -------
Is the mailing-list suggested workaround of adding

   asm ("");

into the not-to-be-inlined test function satisfactory?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563

[Bug tree-optimization/34563] noinline function call being removed

[hp at gcc dot gnu dot org]

------- Comment #11 from hp at gcc dot gnu dot org  2008-01-17 23:09 -------
(In reply to comment #9)
> > Since this topic came up, I've seen various suggestions for how to guarantee
> that a function gets inlined -- e.g., make it a varargs function, or include an
> empty asm statement.

I assume you're referring to the thread at
<http://gcc.gnu.org/ml/gcc/2008-01/msg00165.html>?  If it's elsewhere, I
wouldn't count on it.

> The obvious danger there (aside from the apparent lack of
> clarity as to what constitutes inlining) is that such guarantees are not
> explicit and so may go away the next time gcc developers get ambitious about
> inlining.

Exactly the point of that thread.  The intent is to come to a consensus on the
canonical mechanism, then document it and keep it working.  It seems there's
agreement; I'm just waiting for the issue to go cold with time for
"everybody"'s voice to be heard before fixing the documentation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563

[Bug tree-optimization/34563] noinline function call being removed

[jkenisto at us dot ibm dot com]

------- Comment #12 from jkenisto at us dot ibm dot com  2008-01-18 22:20 -------
(In reply to comment #11)
> (In reply to comment #9)
> > > Since this topic came up, I've seen various suggestions for how to guarantee
> > that a function gets inlined -- e.g., make it a varargs function, or include an
> > empty asm statement.
> 
> I assume you're referring to the thread at
> <http://gcc.gnu.org/ml/gcc/2008-01/msg00165.html>?  If it's elsewhere, I
> wouldn't count on it.

The varargs idea came from the Linux Kernel Mailing List thread I noted in
Comment #7.  The asm idea came from the gcc thread you started -- thanks. 
Plainly, once gcc folks settle on the One Correct Incantation, we'll use that.
(And we can throw out all the other inline-thwarting kludges if that
incantation happens to work for older gcc versions as well... but that's not
your problem.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563