On Tue, 1 Mar 2005, Steven Bosscher wrote:
>>> You still didn't get into the fun part of actually inlining all the
>>> inlines in in Gerald's testcase ;)
> It got killed on a box with 4GB of RAM after 11 hours and 43 minutes
> with "virtual memory exhausted: Cannot allocate memory". In the
> lates
Hello,
I would be interested in testing patches that you produce. It seems
that inlining heuristics have quite a large effect on my code, compared
to other codes.
As an aside, do you (or anyone) know what kind of compile-time speedup
can be gained by boostrapping with more extreme options?
> On Tue, 1 Mar 2005 16:49:04 +0100, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 1 Mar 2005 16:14:14 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >
> > > Concerning growth limits:
> > >
> > > If you take a look on when -finline-unit-growth limit hits, it is clear
> > > that it hit
On Tuesday 01 March 2005 02:30, Steven Bosscher wrote:
> On Tuesday 01 March 2005 02:03, Jan Hubicka wrote:
> > You still didn't get into the fun part of actually inlining all the
> > inlines in in Gerald's testcase ;)
>
> I'll let it run to the end tomorrow, for at most one full day ;-)
It got ki
On Tue, 1 Mar 2005 16:49:04 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Tue, 1 Mar 2005 16:14:14 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>
> > Concerning growth limits:
> >
> > If you take a look on when -finline-unit-growth limit hits, it is clear
> > that it hits very often on
On Tue, 1 Mar 2005 16:14:14 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Concerning growth limits:
>
> If you take a look on when -finline-unit-growth limit hits, it is clear
> that it hits very often on small units (several times in the kernel,
> testsuite and such) just because there is tinn
Hi,
so after reading the whole discussion, here are some of my toughts
for sanity check combined in one to reduce inbox pollution ;)
Concerning Richard's cost tweaks:
There is longer story why I like it ;)
I originally considered further tweaking of cost function as mostly lost
case as the repres
On Tue, 1 Mar 2005 13:46:22 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Looks nice, you might also consider turing next_clone list into doubly
> linked list to speedup remove_node somewhat. Not sure how much that
> one counts.
I'd like to see profiles after the patch first - changing that on
On Tue, 1 Mar 2005 13:41:27 +0100 (CET), Steven Bosscher
<[EMAIL PROTECTED]> wrote:
> On Mar 01, 2005 01:35 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > Try this,. bootstrapped on i686-pc-linux-gnu in progress.
>
> If this works, maybe we should consider this for 4.0 (as a compiler
> speedu
> On Tue, 1 Mar 2005 13:30:41 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > > On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > >
> > > > OK, I will put this higher in the TODO list (but this is not 4.0
> > > > either). What was those less unrealistic tests? I reme
On Mar 01, 2005 01:35 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> Try this,. bootstrapped on i686-pc-linux-gnu in progress.
If this works, maybe we should consider this for 4.0 (as a compiler
speedup), but for 4.1 we should really look into VECs instead of
doubly linked lists.
If your patch
On Tue, 1 Mar 2005 13:30:41 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >
> > > OK, I will put this higher in the TODO list (but this is not 4.0
> > > either). What was those less unrealistic tests? I remember seein
> On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>
> > OK, I will put this higher in the TODO list (but this is not 4.0
> > either). What was those less unrealistic tests? I remember seeing node
> > removal in profiles, but edge removal comes first here. Looks like I
On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> OK, I will put this higher in the TODO list (but this is not 4.0
> either). What was those less unrealistic tests? I remember seeing node
> removal in profiles, but edge removal comes first here. Looks like I
> finally
On Tuesday 01 March 2005 02:03, Jan Hubicka wrote:
> You still didn't get into the fun part of actually inlining all the
> inlines in in Gerald's testcase ;)
I'll let it run to the end tomorrow, for at most one full day ;-)
Gr.
Steven
> On Tuesday 01 March 2005 01:33, Jan Hubicka wrote:
> > > On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > > > > I can only wonder why we are having this discussion just after GCC
> > > > > 4.0 was branched, while it was obvious already two years ago that
> > > > > inlining heuristics
On Tuesday 01 March 2005 01:33, Jan Hubicka wrote:
> > On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > > > I can only wonder why we are having this discussion just after GCC
> > > > 4.0 was branched, while it was obvious already two years ago that
> > > > inlining heuristics were goin
> On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > > I can only wonder why we are having this discussion just after GCC 4.0
> > > was branched, while it was obvious already two years ago that inlining
> > > heuristics were going to be a difficult item with tree-ssa.
> >
> > There were
On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > I can only wonder why we are having this discussion just after GCC 4.0
> > was branched, while it was obvious already two years ago that inlining
> > heuristics were going to be a difficult item with tree-ssa.
>
> There were of course co
> I can only wonder why we are having this discussion just after GCC 4.0
> was branched, while it was obvious already two years ago that inlining
> heuristics were going to be a difficult item with tree-ssa.
There were of course complaints and discussions about this, and I even
tried to tweak inli
On 27 Feb 2005, Gabriel Dos Reis wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> | 5. However, it really might be sensible to have the C++ front end
> | treat "inline" as a command, rather than a hint, by default. It might
>
> For "simple enough" functions. Here, by "simple enough" functi
Steven Bosscher <[EMAIL PROTECTED]> writes:
[...]
| I can only wonder why we are having this discussion just after GCC 4.0
| was branched, while it was obvious already two years ago that inlining
| heuristics were going to be a difficult item with tree-ssa.
my recollection and own feeling is tha
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
[...]
| > The kinds of programs
| > written by these two communities are drastically different, even
| > though, obviously, there is overlap between the two, mixed programs,
| > etc. But, programmers in one camp tend to think that their style is
| > "v
Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
1. The C++ community has split into two sub-communities. One is very
heavily focused on template metaprogramming. The other is doing more
"traditional" object-oriented programming.
I would postulate that most of the times the former
On Monday 28 February 2005 01:46, Giovanni Bajo wrote:
> Richard showed already how his patches help on some of the benchamarks you
> suggested. They also fix a regression since 3.4 was so much better in this
> regard.
And it may introduce new ones.
> Of course, compilation time goes up somehow b
On Feb 27, 2005, at 7:46 PM, Giovanni Bajo wrote:
Richard showed already how his patches help on some of the benchamarks
you
suggested. They also fix a regression since 3.4 was so much better in
this
regard. Of course, compilation time goes up somehow because we are
doing more
work now, but the
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 1. The C++ community has split into two sub-communities. One is very
> heavily focused on template metaprogramming. The other is doing more
> "traditional" object-oriented programming.
I would postulate that most of the times the former group are those
Steven Bosscher <[EMAIL PROTECTED]> wrote:
>> In the end we surely want to watch CiSBE and SPEC testers.
>
> Maybe so, but your timings already show this is pretty unacceptable.
I strongly object this. Benchmarks show that we are doing *much* worse at
inlining in 4.0, and we are seeing bad regre
On 2005-02-27, at 23:39, Andrew Pinski wrote:
On Feb 27, 2005, at 5:30 PM, Steven Bosscher wrote:
Interesting. You of course know Gaby is always claiming the exact
opposite: That the compiler must *honor* the inline keyword (explicit
or "implicit", ie. inline in class definitions), that inline is
On 2005-02-27, at 23:28, Richard Guenther wrote:
People already know to use __attribute__((always_inline)) (ugh!),
When they discover after countelss ours of debugging dessions during
kernel coding
that the compiler suddenly and unpredicably doesn't honor what they
told him explicitely
to do thus
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Feb 27, 2005, at 5:30 PM, Steven Bosscher wrote:
| > Interesting. You of course know Gaby is always claiming the exact
| > opposite: That the compiler must *honor* the inline keyword (explicit
| > or "implicit", ie. inline in class definitions), that
Richard Guenther <[EMAIL PROTECTED]> writes:
[...]
| > Of course, if we can make the compiler automatically do the right thing,
| > that's great. What I'm proposing is a method that would be possibly
| > acceptable for 4.0 that would give people an easy to understand way of
| > getting the compi
Andrew Pinski wrote:
On Feb 27, 2005, at 5:30 PM, Steven Bosscher wrote:
Interesting. You of course know Gaby is always claiming the exact
opposite: That the compiler must *honor* the inline keyword (explicit
or "implicit", ie. inline in class definitions), that inline is not
a hint but an order t
Mark Mitchell <[EMAIL PROTECTED]> writes:
| A few top-level comments on this thread:
|
| 1. The C++ community has split into two sub-communities. One is very
| heavily focused on template metaprogramming. The other is doing more
| "traditional" object-oriented programming. The kinds of program
On Feb 27, 2005, at 5:30 PM, Steven Bosscher wrote:
Interesting. You of course know Gaby is always claiming the exact
opposite: That the compiler must *honor* the inline keyword (explicit
or "implicit", ie. inline in class definitions), that inline is not
a hint but an order that the compiler must
On Sunday 27 February 2005 23:14, Richard Guenther wrote:
> While in theory this could work well, existing code-bases (such as
> POOMA) are notoriously bad in consistently using "inline" (or not).
> I > guess such scheme would work great for most C people, as C people
> generally think twice before
On Sun, 27 Feb 2005 14:23:37 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >> 5. However, it really might be sensible to have the C++ front end
> >> treat "inline" as a command, rather than a hint, by default. It might
> >> be that explicit uses of inline should be
Richard Guenther wrote:
5. However, it really might be sensible to have the C++ front end
treat "inline" as a command, rather than a hint, by default. It might
be that explicit uses of inline should be pretty much unconditionally
honored. (I'd say that functions defined in a class, but not mark
Mark Mitchell wrote:
3. Richard's attempt to discount stuff from being counted unnecessarily
in return statements makes sense to me.
I shifted from avoiding duplicated counting here and there to the goal
that the inliner should not pessimize abstraction by indirection, that
is, the accounted size
A few top-level comments on this thread:
1. The C++ community has split into two sub-communities. One is very
heavily focused on template metaprogramming. The other is doing more
"traditional" object-oriented programming. The kinds of programs
written by these two communities are drastically
Jan Hubicka <[EMAIL PROTECTED]> writes:
[...]
| Basically we need to explain inliner that the abstraction functions are
| free to get sane results on C++...
\o/
[...]
| The only problem with common heuristics I see is that in C the "inline"
| keyword is very strong hint basically meaning
> How do you suppose we fix the three-fold run-time performance
> regressions I and other people see for their scientific code?
right! in other words, do you want 4.0 to be a developer-only release,
or do you want anyone to use it to compile actual applications?
at least in my world, compilers
Jan Hubicka wrote:
Or have different inlining heuristics for C++.
I tend to thing that common heuristics smart enought to catch C++
abstraction should do fine for both. Inlining is hitting us before each
release, now imagine twice as many arugments here!
The only problem with common heuristics I
> On Sunday 27 February 2005 14:58, Jan Hubicka wrote:
> > > >is a problem for a few people, but if you look at the performance
> > > >numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear
> > > >to be any performance problem. But your patch will probably still
> > > >blow compile ti
> Richard Guenther writes:
>... I also think our in-lining limits are way too high,
> at least unnecessary high with the patch applied...
- If function-call overhead could be more accurately estimated, possibly
by enabling the inclusion of set/move instructions in rtl cost estimates to
Steven Bosscher wrote:
On Sunday 27 February 2005 14:58, Jan Hubicka wrote:
is a problem for a few people, but if you look at the performance
numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear
to be any performance problem. But your patch will probably still
blow compile time thro
Steven Bosscher wrote:
On Sunday 27 February 2005 14:58, Jan Hubicka wrote:
is a problem for a few people, but if you look at the performance
numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear
to be any performance problem. But your patch will probably still
blow compile time thro
Jan Hubicka wrote:
To just add another data-point, metaprograms like the following are very
common. Consider
template
struct Add
{
static inline int doit(int *x)
{
return Add::doit(x)+x[i];
}
};
template <>
struct Add<0>
{
static inline int doit(int *x)
On Sunday 27 February 2005 14:58, Jan Hubicka wrote:
> > >is a problem for a few people, but if you look at the performance
> > >numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear
> > >to be any performance problem. But your patch will probably still
> > >blow compile time through
> To just add another data-point, metaprograms like the following are very
> common. Consider
>
> template
> struct Add
> {
> static inline int doit(int *x)
> {
> return Add::doit(x)+x[i];
> }
> };
> template <>
> struct Add<0>
> {
> static inline
> Steven Bosscher wrote:
> >On Sunday 27 February 2005 10:57, Richard Guenther wrote:
> >
> >>Steven Bosscher wrote:
> >>
> >>>On Feb 27, 2005 02:04 AM, Richard Guenther
> >
> ><[EMAIL PROTECTED]> wrote:
> >
> In the end we surely want to watch CiSBE and SPEC testers.
> >>>
> >>>Maybe so, but
To just add another data-point, metaprograms like the following are very
common. Consider
template
struct Add
{
static inline int doit(int *x)
{
return Add::doit(x)+x[i];
}
};
template <>
struct Add<0>
{
static inline int doit(int *x)
{
I take it as a lame property of our current inlining heuristics
and function size estimate that for
inline int foo { return 0; }
int bar { return foo(); }
the size estimate of foo is 2, that of bar is initially 13 and 5
after inlining. 3.4 did better in that it has 1 for foo, 12 for bar
before
Steven Bosscher wrote:
On Sunday 27 February 2005 10:57, Richard Guenther wrote:
Steven Bosscher wrote:
On Feb 27, 2005 02:04 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
In the end we surely want to watch CiSBE and SPEC testers.
Maybe so, but your timings already show this is pretty unacceptab
On Sunday 27 February 2005 10:57, Richard Guenther wrote:
> Steven Bosscher wrote:
> > On Feb 27, 2005 02:04 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> >>In the end we surely want to watch CiSBE and SPEC testers.
> >
> > Maybe so, but your timings already show this is pretty unacceptable.
>
> Steven Bosscher wrote:
> >On Feb 27, 2005 02:04 AM, Richard Guenther
> ><[EMAIL PROTECTED]> wrote:
> >
> >>In the end we surely want to watch CiSBE and SPEC testers.
> >
> >
> >Maybe so, but your timings already show this is pretty unacceptable.
>
> Well, the compile time regressions are not ca
On Sun, 27 Feb 2005 02:04:19 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> Steven Bosscher wrote:
> > On Saturday 26 February 2005 23:03, Jan Hubicka wrote:
> >
> >>Mark? I would say that there is little risk in this patch corectness
> >>wise, might have negative effect on compilation times
Steven Bosscher wrote:
On Feb 27, 2005 02:04 AM, Richard Guenther <[EMAIL PROTECTED]> wrote:
In the end we surely want to watch CiSBE and SPEC testers.
Maybe so, but your timings already show this is pretty unacceptable.
Well, the compile time regressions are not caused by my patch but only
expos
On Feb 27, 2005 02:04 AM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> In the end we surely want to watch CiSBE and SPEC testers.
Maybe so, but your timings already show this is pretty unacceptable.
Gr.
Steven
Steven Bosscher wrote:
On Saturday 26 February 2005 23:03, Jan Hubicka wrote:
Mark? I would say that there is little risk in this patch corectness
wise, might have negative effect on compilation times since we re-start
inlining more like we did in old days.
Can we see some timings with and withou
Jan Hubicka wrote:
On Thu, 24 Feb 2005 20:05:37 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote:
Also, for the simple function
double foo1(double x)
{
return x;
}
we return 4 as a cost, because we have
double tmp = x;
return tmp;
and count the move cost (MODIFY_EXPR) t
Steven Bosscher wrote:
On Saturday 26 February 2005 23:03, Jan Hubicka wrote:
Mark? I would say that there is little risk in this patch corectness
wise, might have negative effect on compilation times since we re-start
inlining more like we did in old days.
Can we see some timings with and withou
On Saturday 26 February 2005 23:03, Jan Hubicka wrote:
> Mark? I would say that there is little risk in this patch corectness
> wise, might have negative effect on compilation times since we re-start
> inlining more like we did in old days.
Can we see some timings with and without this patch?
Gr
> On Thu, 24 Feb 2005 20:05:37 +0100, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
> > Jan Hubicka wrote:
> >
> > >>Also, for the simple function
> > >>
> > >>double foo1(double x)
> > >>{
> > >>return x;
> > >>}
> > >>
> > >>we return 4 as a cost, because we have
> > >>
> > >> double t
On Thu, 24 Feb 2005 20:05:37 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> Jan Hubicka wrote:
>
> >>Also, for the simple function
> >>
> >>double foo1(double x)
> >>{
> >>return x;
> >>}
> >>
> >>we return 4 as a cost, because we have
> >>
> >> double tmp = x;
> >> return tmp;
>
Jan Hubicka wrote:
Also, for the simple function
double foo1(double x)
{
return x;
}
we return 4 as a cost, because we have
double tmp = x;
return tmp;
and count the move cost (MODIFY_EXPR) twice. We could fix this
by not walking (i.e. ignoring) RETURN_EXPR.
That would work, yes. I wa
> Hi!
>
> I'm looking at improving inlining heuristics at the moment,
> especially by questioning the estimate_num_insns. All uses
> of that function assume it to return a size cost, not a computation
> cost - is that correct? If so, why do we penaltize f.i. EXACT_DIV_EXPR
> compared to MULT_EXP
On Thu, 24 Feb 2005, Steven Bosscher wrote:
> On Feb 24, 2005 01:58 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > I'm looking at improving inlining heuristics at the moment,
> > especially by questioning the estimate_num_insns.
>
> Good. There is lots of room for improvement there.
>
> > A
On Feb 24, 2005 01:58 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I'm looking at improving inlining heuristics at the moment,
> especially by questioning the estimate_num_insns.
Good. There is lots of room for improvement there.
> All uses
> of that function assume it to return a size cos
Hi!
I'm looking at improving inlining heuristics at the moment,
especially by questioning the estimate_num_insns. All uses
of that function assume it to return a size cost, not a computation
cost - is that correct? If so, why do we penaltize f.i. EXACT_DIV_EXPR
compared to MULT_EXPR?
Also, for
71 matches
Mail list logo
