[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Comment #7 from ash at onezero dot org 2005-12-10 06:23 --- (In reply to comment #6) > (In reply to comment #5) > > Yes, I'm running the most recent one of those. The discussion in the > > cygwin > > lists does not make it appear that it is easy to compile and install gcc. > That is not true but what ever. > No feedback in 3 months so closing as invalid. What is not true but what ever? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug c/23769] New: always inline short functions if inlining would be as small as non-inlined code
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
[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18 --- I'm on Cywin and couldn't find a later version of gcc - is there one somewhere that I can use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18 --- (Cygwin) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Additional Comments From ash at onezero dot org 2005-09-10 02:33 --- Yes, I'm running the most recent one of those. The discussion in the cygwin lists does not make it appear that it is easy to compile and install gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug c/23846] New: suggest new warning (example: int x = x)
gcc -std=c99 -Wall gives no errors or warnings when an initialization (right
side of =) refers to the value being initialized (left side of =). This is
true if the item being dereferenced has an indeterminate value, e.g., is a
local variable:
| cat t.c
#include
int main()
{
int array[] = { 1, 2 };
int x = 0;
int y = array[y];
printf("x=%d y=%d", x, y);
}
| gcc --version
gcc (GCC) 3.3.3 (cygwin special)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
| gcc -Wall -std=c99 -o t t.c
| ./t
x=0 y=1
|
In this case the programmer made a mistake and meant to use "array[x]" in the
initialization of y.
I just found this in my own code - it is an easy mistake to make when doing a
mass transformation of code. I was lucky because the line generated a bus
error, but this error could be insidious because the code could work in some
environments.
My guess is that the vast majority of cases where the lvalue being initialized
is deferenced on the right side of an initialization are mistakes. If this is
permitted by the standard, presumably to ease doing things like "int* x = &x",
then maybe a new warning could be created (probably "on" by default, or part
of "-Wall").
--
Summary: suggest new warning (example: int x = x)
Product: gcc
Version: 3.3.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P1
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=23846
[Bug c/23846] suggest new warning (example: int x = x)
--- Additional Comments From ash at onezero dot org 2005-09-13 04:08 --- I'll look forward to trying it out.. I've got to figure out a way to get gcc 4. I wish gcc 4 was available with Cygwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23846
