[Bug tree-optimization/34563] noinline function call being removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #13 from Andrew Pinski --- Dup of bug 16922. *** This bug has been marked as a duplicate of bug 16922 ***
[Bug tree-optimization/34563] noinline function call being removed
--- 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
[Bug tree-optimization/34563] noinline function call being removed
--- 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-kernelm=119991179332571w=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
--- 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
--- 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
--- 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-kernelm=119991179332571w=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
--- 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-kernelm=119991179332571w=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
--- 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
