tree 4f470bb9387a914e2675c6f195aefc79e2ecfdb1
parent 0a8600da5a0485c62404c4db3fad84e286c37154
author Christoffer Quist Adamsen <christofferqa@google.com> 1530788133 +0200
committer Christoffer Quist Adamsen <christofferqa@google.com> 1530788133 +0200

Towards an inlining oracle for jar code

It is only possible to merge a type A into its subtype B if A.<init>() can be inlined into B.<init>(). Thus we need to be sure that A.<init>() can in fact be inlined into B.<init>() *before* we merge the two classes.

The current infrastructure does not allow us to determine if this is possible, since we only have the jar code available by the time we run the vertical class merger, and the inliner looks at the instructions in the IR to determine if a method is eligible for inlining (see Inliner.computeInliningConstraint).

To address this problem, this CL creates a new visitor for ASM code called InliningConstraintVisitor that carries out the same checks as Inliner.computeInliningConstraint.

(Note that the implementation of InliningConstraintVisitor is still incomplete.)

Change-Id: I535425554bbeba4da0a2bd57f281a866b7ffdcef