This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]