This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Please try out new inlining heuristics
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 28 Jun 2003 12:32:25 +0200 (CEST)
- Subject: Re: Please try out new inlining heuristics
> Would be possible for you to construct simple testcase where I can see
> the problem?
In POOMA there are a lot of methods where inlining them they expand to
"nothing". Like pure abstraction, f.i.
struct foo;
template <>
struct bar<foo> {
static inline foo::Return_t& foobar(const foo& f) { return foo::foobar(f); }
};
Such function should not count at all, after being inlined. I.e. you need
to "subtract" some size points if you inline it and such it size should
become zero.
The other common idiom is loops sized by an integer template parameter
which is of the order of 1-3:
template <int Dim>
struct foo {
static void doloop(const bar& b) {
for (int i=0; i<Dim; ++i)
b[i].doone();
}
};
Ideally, this would count as n*Dim statements - but I realize this is hard
to do until we do loop optimization and constant propagation at the tree
level. The same goes for switch and if statements dependent on template
arguments.
Also it happens to me quite often that empty constructors and destructors
are not inlined, like in
template <int Dim>
struct foo {
foo() {}
~foo() {}
int data[Dim];
};
Thanks for your work,
Richard.