We should also keep in mind that such logs aimed at users should support
i18n - unlike the existing dumps for compiler developers, which are quite
properly English only, and most calls to internal_error which should only
appear if there is a compiler bug and are also only meant to be useful for
-Winline doesn't help here. Scanning the assember output does (obviously!).
nm also does.
Paolo
Jan Hubicka wrote:
Yes, I would be interested. It seems that for osme reason the other
functions are not considered to be called once, perhaps a visibility
issue. We also should say what limit was reached on inlining hlprog.
Sent off bzip2'd tar file.
--
Toon Moene - e-mail: t...@moene.org
On Wed, Oct 14, 2009 at 04:33:35PM +0200, Jan Hubicka wrote:
> > Deciding on smaller functions:
> > Considering inline candidate phcall_.clone.3.
> > Inlining failed: --param max-inline-insns-auto limit reached
> Yes, I would be interested. It seems that for osme reason the other
> functions are
> Richard Guenther wrote:
>
> >It'll be in /tmp and named after the first object file, in your case it
> >will
> >be ccGGS24.o.047i.inline (because the first object file will be a
> >tempfile). A minor inconvenience that maybe is going to be fixed.
>
> Now that Richard has pointed out to me whe
Richard Guenther wrote:
It'll be in /tmp and named after the first object file, in your case it will
be ccGGS24.o.047i.inline (because the first object file will be a
tempfile). A minor inconvenience that maybe is going to be fixed.
Now that Richard has pointed out to me where the info is, I
Richard Guenther wrote:
On Tue, Oct 13, 2009 at 8:31 PM, Toon Moene wrote:
gfortran -o exe -O3 -flto -fwhole-program -fdump-ipa-inline a.f lib.a
?
It'll be in /tmp and named after the first object file, in your case it will
be ccGGS24.o.047i.inline (because the first object file will be a
On Tue, Oct 13, 2009 at 8:31 PM, Toon Moene wrote:
> 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
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 inlining decisions and if
something is not inlined,
Paul Brook writes:
>> Nothing you've said changes the fact that there are a class of users
>> for whom that information is vital and we ought to spend some time
>> thinking about how to provide the information in a form they can
>> digest. GCC dumps as they exist today are largely useless for a
On 10/13/09 03:41, Paul Brook wrote:
Nothing you've said changes the fact that there are a class of users
for whom that information is vital and we ought to spend some time
thinking about how to provide the information in a form they can
digest. GCC dumps as they exist today are largely useless
On Tue, Oct 13, 2009 at 10:41:39AM +0100, Paul Brook wrote:
> My guess is anyone inspecting the code and optimizer decisions at this level
> is also going to want to strongarm the result they want when the compiler
> makes the "wrong" decision. i.e. detailed unroller diagnostics are only of
> li
> Nothing you've said changes the fact that there are a class of users
> for whom that information is vital and we ought to spend some time
> thinking about how to provide the information in a form they can
> digest. GCC dumps as they exist today are largely useless for a non-GCC
> developer to u
On 10/12/09 19:18, Michael Matz wrote:
Hi,
On Mon, 12 Oct 2009, Jeff Law wrote:
To put things in perspective, the particular person I spoke with spent
many days trying to understand why a particular function wasn't being
inlined -- presumably they'd see "grep logfile" as a
huge improvemen
Hi,
On Mon, 12 Oct 2009, Jeff Law wrote:
> To put things in perspective, the particular person I spoke with spent
> many days trying to understand why a particular function wasn't being
> inlined -- presumably they'd see "grep logfile" as a
> huge improvement over the days and days of twiddli
On 10/10/09 10:40, Richard Guenther wrote:
Well - that will print one diagnostic per callgraph edge. A bit too much, no?
Possibly -- it's not yet clear (to me) how to present this data to
users, but it's clearly something they're interested in.
To put things in perspective, the particula
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
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
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
>>>
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
32 matches
Mail list logo
