Please try out new inlining heuristics

[Jan Hubicka]

> > 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.

We are subtracting 10 (one statement of the size), so this should be
fine.
I am experimenting with the idea of abstraction penalty arugment that
simply subctract given portion of function body after inlining assuming
that it will be elliminated (so it preffer inlining larger functions
when these were created by inlining many other functions together)
> 
> 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.

Yes, we can't get into this busyness right now :(
> 
> 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];
> };

I will try this one :)

Honza
> 
> 
> Thanks for your work,
> 
> Richard.
>