* Re: Patch to -Os
@ 1998-02-02 17:14 Mike Stump
0 siblings, 0 replies; 6+ messages in thread
From: Mike Stump @ 1998-02-02 17:14 UTC (permalink / raw)
To: egcs, pcg
> Date: Sat, 31 Jan 1998 21:02:07 +0100
> From: Marc Lehmann <pcg@goof.com>
> +#define INTEGRATE_THRESHOLD(DECL) (optimize_size \
> + ? (1 + (3 * list_length (DECL_ARGUMENTS (DECL) / 2))) \
> + : (8 * (8 + list_length (DECL_ARGUMENTS (DECL)))))
Ick! Is there some reason why this cannot be made machine
independent? I mean, the mi def is:
/* Default max number of insns a function can have and still be inline.
This is overridden on RISC machines. */
#ifndef INTEGRATE_THRESHOLD
#define INTEGRATE_THRESHOLD(DECL) \
(8 * (8 + list_length (DECL_ARGUMENTS (DECL))))
#endif
(from integrate.c) which looks suspiciously like your def, only worse.
Why not change it (fix it) instead?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Patch to -Os
1998-01-31 12:09 Marc Lehmann
1998-01-31 18:04 ` Joe Buck
@ 1998-02-01 1:05 ` Jeffrey A Law
1 sibling, 0 replies; 6+ messages in thread
From: Jeffrey A Law @ 1998-02-01 1:05 UTC (permalink / raw)
To: Marc Lehmann; +Cc: egcs
In message <19980131210207.45108@cerebro.laendle>you write:
> anyway, here's a small patch that might make more sense than to disable
> -finline-functions altogether with -Os.
>
> The idea is that a function call is at least 1 instruction (call) plus 1.5
> instructions per argument (well, constants are one or two insns, simple
> variables are one or two insns..), so doing the inline with small functions
> might be even better than calling them, since the actual call needs more
> instructions (there _are_ such functions!)
>
> The patch re-enables -finline-functions with -Os and sets
> INTEGRATE_THRESHOLD to a small value when -Os is specified.
>
> Another (maybe much better!) approach would be to do this for
> all architectures, i.e. leaving flagh_inline_functions alone
> and just making the default for INTEGRATE_THRESHOLD smaller
> (although architectures that aslready define INTEGRATE_THRESHOLD
> need a change, then).
>
> any comments?
Well, I'd personally prefer to see flag_inline_funtions set for
-On for n > 2 (or maybe 3 since it can have much more of a size
impact than loop unrolling) in the machine independent code rather
than doing it in each backend.
Similarly for INTEGRATE_THRESHOLD, the change belongs in the target
independent code.
Can you rework your patch in that manner?
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Patch to -Os
1998-01-31 22:46 ` Stephen Williams
@ 1998-02-01 0:37 ` Jeffrey A Law
0 siblings, 0 replies; 6+ messages in thread
From: Jeffrey A Law @ 1998-02-01 0:37 UTC (permalink / raw)
To: Stephen Williams; +Cc: Joe Buck, egcs
In message <199802010646.WAA09109@icarus.icarus.com>you write:
> I find that optimizing for speed and space are not necessarily exclusive.
> I fight for every byte of space when writing embedded C++ code.
Correct. Many "speed" optimizations also help codesize.
However, there are some ways to improve codesize that will hurt
speed. I think a list of these things may have been posted to the
list back in Aug/Sept. Right now -Os does little (if anything)
however, we can start tuning various optimizers to be "space"
aware. That old list will be a good starting point.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Patch to -Os
1998-01-31 18:04 ` Joe Buck
@ 1998-01-31 22:46 ` Stephen Williams
1998-02-01 0:37 ` Jeffrey A Law
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Williams @ 1998-01-31 22:46 UTC (permalink / raw)
To: Joe Buck; +Cc: egcs
> The idea is that a function call is at least 1 instruction (call) plus 1.5
> instructions per argument (well, constants are one or two insns, simple
> variables are one or two insns..), so doing the inline with small functions
> might be even better than calling them, since the actual call needs more
> instructions (there _are_ such functions!)
jbuck@synopsys.com said:
> Yes, such functions are extremely common in C++ (e.g. a member
> function that just returns some field of a class). Out-of-line calls
> will not save space. It would make sense to always inline extremely
> small functions, for a suitable definition of small, even when
> optimizing for space.
I find that optimizing for speed and space are not necessarily exclusive.
I fight for every byte of space when writing embedded C++ code.
I think that the simple instruction count is not enough to express the
advantage of proper inlining. Often, code that is inlined can shrink more
then otherwise thanks to CSE, constant propagation, whatever, so that even
some functions longer then a function call reduce to smaller then a call
sequence. Indeed, sometimes it reduces to <0 size!
--
Steve Williams "The woods are lovely, dark and deep.
steve@icarus.com But I have promises to keep,
steve@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Patch to -Os
1998-01-31 12:09 Marc Lehmann
@ 1998-01-31 18:04 ` Joe Buck
1998-01-31 22:46 ` Stephen Williams
1998-02-01 1:05 ` Jeffrey A Law
1 sibling, 1 reply; 6+ messages in thread
From: Joe Buck @ 1998-01-31 18:04 UTC (permalink / raw)
To: Marc Lehmann; +Cc: egcs
> The idea is that a function call is at least 1 instruction (call) plus 1.5
> instructions per argument (well, constants are one or two insns, simple
> variables are one or two insns..), so doing the inline with small functions
> might be even better than calling them, since the actual call needs more
> instructions (there _are_ such functions!)
Yes, such functions are extremely common in C++ (e.g. a member function that
just returns some field of a class). Out-of-line calls will not save
space. It would make sense to always inline extremely small functions,
for a suitable definition of small, even when optimizing for space.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Patch to -Os
@ 1998-01-31 12:09 Marc Lehmann
1998-01-31 18:04 ` Joe Buck
1998-02-01 1:05 ` Jeffrey A Law
0 siblings, 2 replies; 6+ messages in thread
From: Marc Lehmann @ 1998-01-31 12:09 UTC (permalink / raw)
To: egcs
The new -Os switch is a wonderful idea (for example it let me remove the
-fopt-size option from pgcc ;)
anyway, here's a small patch that might make more sense than to disable
-finline-functions altogether with -Os.
The idea is that a function call is at least 1 instruction (call) plus 1.5
instructions per argument (well, constants are one or two insns, simple
variables are one or two insns..), so doing the inline with small functions
might be even better than calling them, since the actual call needs more
instructions (there _are_ such functions!)
The patch re-enables -finline-functions with -Os and sets
INTEGRATE_THRESHOLD to a small value when -Os is specified.
Another (maybe much better!) approach would be to do this for
all architectures, i.e. leaving flagh_inline_functions alone
and just making the default for INTEGRATE_THRESHOLD smaller
(although architectures that aslready define INTEGRATE_THRESHOLD
need a change, then).
any comments?
1998-01-31 Marc Lehmann <pcg@goof.com>
* config/i386/i386.h (INTEGRATE_THRESHOLD): New define.
* config/i386/i386.c (optimization_options): Enable
flag_inline_functions even when -Os is specified.
--- gcc/config/i386/i386.c.orig Sat Jan 31 20:42:21 1998
+++ gcc/config/i386/i386.c Sat Jan 31 20:46:32 1998
@@ -420,6 +420,9 @@
if (level > 1)
flag_schedule_insns = 0;
#endif
+
+ if (level > 2)
+ flag_inline_functions = 1;
}
\f
/* Sign-extend a 16-bit constant */
--- gcc/config/i386/i386.h.orig Sat Jan 31 20:42:15 1998
+++ gcc/config/i386/i386.h Sat Jan 31 20:45:19 1998
@@ -1855,6 +1855,14 @@
is a byte address (for indexing purposes)
so give the MEM rtx a byte's mode. */
#define FUNCTION_MODE QImode
+
+/* A C expression for the maximum number of instructions above which
+ the function DECL should not be inlined. DECL is a
+ 'FUNCTION_DECL' node. */
+
+#define INTEGRATE_THRESHOLD(DECL) (optimize_size \
+ ? (1 + (3 * list_length (DECL_ARGUMENTS (DECL) / 2))) \
+ : (8 * (8 + list_length (DECL_ARGUMENTS (DECL)))))
\f
/* A part of a C `switch' statement that describes the relative costs
of constant RTL expressions. It must contain `case' labels for
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1998-02-02 17:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-02-02 17:14 Patch to -Os Mike Stump
-- strict thread matches above, loose matches on Subject: below --
1998-01-31 12:09 Marc Lehmann
1998-01-31 18:04 ` Joe Buck
1998-01-31 22:46 ` Stephen Williams
1998-02-01 0:37 ` Jeffrey A Law
1998-02-01 1:05 ` Jeffrey A Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).