From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5462 invoked by alias); 7 Sep 2005 19:11:31 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 5446 invoked by uid 48); 7 Sep 2005 19:11:26 -0000 Date: Wed, 07 Sep 2005 19:11:00 -0000 From: "ash at onezero dot org" To: gcc-bugs@gcc.gnu.org Message-ID: <20050907191121.23769.ash@onezero.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c/23769] New: always inline short functions if inlining would be as small as non-inlined code X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg00849.txt.bz2 List-Id: I noticed when compiling with gcc -std=c99 -Winline that this function inline uint16_t f(uint16_t x) { return x; } wasn't getting inlined. Inlining is also not done even when the function is attributed with "__attribute__ ((always_inline))", nor does inlining happen when there no attributes at all. Maybe this function isn't getting inlined because the compiler decided that it would involve in some sense "too much" expansion in the caller. Regardless of this particular case, I wonder if the following enhancement to gcc would be worthwhile: always inline when it can be deduced that the code with inlining would be no larger than the code without inlining, regardless of the size of the caller in whatever representation is used at the time this decision is being made. For example, on many architectures, a call to a function that accepts an argument and returns a value will use at least 3 instructions in the caller: one to push the argument onto the stack, one to call the function, and one to retrieve the return value from the function. So, if the function uses up to three instructions to do its calculation, plus a return statement (with no calculation in the return), then inlining will use no more instruction space than not inlining. In these cases, inlining probably ought to be done so as to create opportunities for further optimizations later, e.g., common subexpression elimination. A more sophisticated determination could take into account the number of arguments and other factors. This might be especially helpful with C++ programs that have a lot of short methods. At least, this is how it looks to me - if I am wrong, maybe someone could educate me a bit or point me to some documentation where I can learn more about how gcc's inlining works. If inlining is supposed to work this way already, then I'll be happy to try to isolate the code further so that we have a small fully compilable example. I'm compiling with this: gcc -o t.exe -DZCodeTest -g -DZAssert -D__GCC__ -std=c99 -O3 -pedantic -Werror - Wall -W -I. -Wundef -Wshadow -Wpointer-arith -Wcast-qual -Wbad-function-cast - Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations - Wredundant-decls -Wdisabled-optimization -Winline t.c -- Summary: always inline short functions if inlining would be as small as non-inlined code Product: gcc Version: 3.3.1 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ash at onezero dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769