Re: Inlining on trees

[Geoff Keating <geoffk at ozemail dot com dot au>]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     I disagree, actually.  I'd certainly like to see the new tree-based
>     inlining working before killing integrate.c.  And, there might still
>     be reasons why integrate.c might be useful; there are languages (like
>     Ada and Pascal) that are not yet in the tree but will be at some
>     point.
> 
> I feel the same way you do, but not quite for the same reason.  I can't
> speak to Pascal but Ada could trivially convert to function- or file-at-time
> compilation since the front end already compiles the entire file into Ada
> abstract syntax trees before calling the backend at all.  There are definite
> advantages to tree based inlining (and the Ada front-end already does some),
> but I'm not convinced that the opposite isn't true, that there might not
> be some cases where the RTL based inlining might be better. I can't think
> of any such right now, since it certainly *seems* like the tree level is
> the most efficient for inlining, but there are plenty of cases where RTL
> is the best level for optimizations, so I'm not convinced I'm not missing
> something here.

Assuming that the new inlining scheme can actually inline in all the
cases when we could do it with RTL, which I think it can, the only
other parameter is _when_ to inline.  For this, RTL is slightly more
helpful, because you have an insn count; but really, what you want is
the insn _cost_ after inlining and after optimisation, which is a
completely different thing.

For loop unrolling, which I think we're also considering doing at the
tree level, this is much more important.  You really want to know how
fast the loop will go, and how large it is, if it is unrolled 1, 2, 4,
... times.  It may be that the best thing to do is to try unrolling it
and reduce it to RTL and optimise it a bit and then see if it
helped---of course, we couldn't even try to do that if we were
unrolling in RTL form.

-- 
Geoffrey Keating <geoffk@cygnus.com>