Jan Hubicka wrote:
We already have -Winline that dumps same info for all functions marked
inline. I am not sure if warning about all functions would help too
much, but I might be C centric where if I wanted to get something
inlined, I would use inline keyword :)
I must say I learned *a lot* a
On Sat, 10 Oct 2009, Diego Novillo wrote:
> On Sat, Oct 10, 2009 at 11:17, Daniel Jacobowitz wrote:
> > On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote:
> >> My solution would be probably to pass -fdump-ipa-inline parameter to lto
> >> compilation and read the log. It lists the inlin
On Sat, Oct 10, 2009 at 6:24 PM, Jeff Law wrote:
> On 10/10/09 09:17, Daniel Jacobowitz wrote:
>>
>> On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote:
>>
>>>
>>> My solution would be probably to pass -fdump-ipa-inline parameter to lto
>>> compilation and read the log. It lists the inli
On 10/10/09 09:17, Daniel Jacobowitz wrote:
On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote:
My solution would be probably to pass -fdump-ipa-inline parameter to lto
compilation and read the log. It lists the inlining decisions and if
something is not inlined, you get dump of re
This is the beta release of binutils 2.20.51.0.2 for Linux, which is
based on binutils 2009 1009 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On Sat, Oct 10, 2009 at 11:17, Daniel Jacobowitz wrote:
> On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote:
>> My solution would be probably to pass -fdump-ipa-inline parameter to lto
>> compilation and read the log. It lists the inlining decisions and if
>> something is not inlined, y
> On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote:
> > My solution would be probably to pass -fdump-ipa-inline parameter to lto
> > compilation and read the log. It lists the inlining decisions and if
> > something is not inlined, you get dump of reason why.
>
> GCC's dumps are really
On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote:
> My solution would be probably to pass -fdump-ipa-inline parameter to lto
> compilation and read the log. It lists the inlining decisions and if
> something is not inlined, you get dump of reason why.
GCC's dumps are really aimed at co
2009/10/10 Sergey Sadovnikov :
> Hello.
>
> There is linkage problem with recent gcc 4.5 in MinGW configuration
> build. Executables which are produced by gcc with default options set
> treated as 'not a valid win32 application' by the system (Win2008 x64
> server). After stripping with the 'strip'
On Sat, Oct 10, 2009 at 3:40 PM, Toon Moene wrote:
> Toon Moene wrote:
>
>> Richard Guenther wrote:
>
>>> Or rather for testing the effect of inlining all functions called once
>>> use the following
>>> patch:
>>>
>>> Index: ipa-inline.c
>>>
Hello.
There is linkage problem with recent gcc 4.5 in MinGW configuration
build. Executables which are produced by gcc with default options set
treated as 'not a valid win32 application' by the system (Win2008 x64
server). After stripping with the 'strip' utility executables are
successfully ran.
Toon Moene wrote:
Richard Guenther wrote:
Or rather for testing the effect of inlining all functions called once
use the following
patch:
Index: ipa-inline.c
===
--- ipa-inline.c(revision 152615)
+++ ipa-inline.c(working
> On Sat, Oct 10, 2009 at 12:55 PM, Toon Moene wrote:
> > Gcc's man page says:
> >
> > -finline-functions-called-once
> > Consider all "static" functions called once for inlining into
> > their caller even if they are not marked "inline". If a call
> > to a giv
Richard Guenther wrote:
On Sat, Oct 10, 2009 at 1:46 PM, Richard Guenther
wrote:
On Sat, Oct 10, 2009 at 1:34 PM, Toon Moene wrote:
[ Inlining all functions called once ]
I'd like to see some fireworks, too !
That's not the parameter you want to tweak ;) You want
--param large-function
On Sat, Oct 10, 2009 at 1:46 PM, Richard Guenther
wrote:
> On Sat, Oct 10, 2009 at 1:34 PM, Toon Moene wrote:
>> Richard Guenther wrote:
>>
>>> On Sat, Oct 10, 2009 at 12:55 PM, Toon Moene wrote:
>>
>>> Well, I think that we should try to not do this across the whole program.
>>> Simply for the
On Sat, Oct 10, 2009 at 1:34 PM, Toon Moene wrote:
> Richard Guenther wrote:
>
>> On Sat, Oct 10, 2009 at 12:55 PM, Toon Moene wrote:
>
>> Well, I think that we should try to not do this across the whole program.
>> Simply for the reason that a gigantic main function will hit several
>> non-linea
Richard Guenther wrote:
On Sat, Oct 10, 2009 at 12:55 PM, Toon Moene wrote:
Well, I think that we should try to not do this across the whole program.
Simply for the reason that a gigantic main function will hit several
non-linear complexity algorithms in GCC.
But, but ... other people are
On Sat, Oct 10, 2009 at 12:55 PM, Toon Moene wrote:
> Gcc's man page says:
>
> -finline-functions-called-once
> Consider all "static" functions called once for inlining into
> their caller even if they are not marked "inline". If a call
> to a given function is
Gcc's man page says:
-finline-functions-called-once
Consider all "static" functions called once for inlining into
their caller even if they are not marked "inline". If a call
to a given function is integrated, then the function is not
output as
Quoting Li Feng :
So my question is,
1. Is this necessary/correct if we want to escape the re-optimization for the
first few passes before tree-parloop.c and continue the optimization passes
after it for the function fun.loop_f0, there must be compile time
savings if we
do this in my opinion
I wrote:
On our weather forecasting code (compiled with -O3 -flto and linked with
-O3 -flto -fwhole-program) I get a speedup of 65 seconds per time step
in the model integration vs. 75 seconds with -O3 alone.
That is a 10/75 ~ 13 % improvement.
This morning I tried again, with a freshly upd
21 matches
Mail list logo
