Re: Simple inlining question

[Archie Cobbs <archie@dellroad.org>]

Ondrej Lhotak wrote:
> > What I would like to do is add "simple" inlining to the above
> > optimizations. That is, I'd like to have Soot look at all call
> > sites and inline those whose target is either a static, private,
> > or final method (i.e., known target) and is suitable for inlining
> > (e.g., fairly short, not INVOKESPECIAL, etc).
> 
> Soot's inliner is in the phase wjop.si, and its code is in the
> StaticInliner class. The code there uses the call graph and various
> heuristics to decide what to inline, then uses SiteInliner to actually
> do the inlining. Assuming you don't have a call graph, you can either
> make up a call graph that will get the StaticInliner to inline the sites
> you want, or just use the StaticInliner code as a starting point for
> writing your own class to decide what to inline or not. You definitely
> shouldn't need to do the inlining itself yourself; that's done in
> SiteInliner.

Thanks .. fyi, it's working great. I'm using SiteInliner to do the
actual work and using my own customized criteria. 

During this work an idea occurred to me which probably has already
been thought about, but figured that I'd run it by the list and get
some opinions.

There are lots of "implied" operations that are done by Java bytecodes.
For example, array bounds checks are implied by array access instructions.
Null pointer checks are implied by nonvirtual INVOKESPECIAL, etc.

Often these can be optimized away. For example, when inlining a nonvirtual
INVOKESPECIAL, an explicit null pointer check must be added (this is
done in SiteInliner by adding the relevant Jimple instructions). But of
course if the base object of the invocation is "this", then you know that
it's not null because you're already executing within a non-static method,
so the null check can be removed. Etc.

Of course, these optimizations are only useful if you're converting class
files into something else besides Java bytecode (that's what my application
does, so we have at least one example :-)

So why not create new, explicit Jimple Stmt's that represent these
implicit operations? Then they could be optimized away using normal
analysis techniques. If converting back to Java, you'd just ignore them.

My question then is: how hard would such an idea be to implement? That is,
how hard is it to add new Jimple statement and/or expression types without
invalidating all the existing optimizations, etc?

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com