[Soot-list] Prevent static array fill code getting pessimized to use aload+astore instead of dup?

[Noam Postavsky]

On Fri, Jul 11, 2014 at 12:25 AM, Patrick Lam <plam at sable.mcgill.ca> wrote:
> See the CC 2000 paper about Soot bytecode generation. There should be a
> LoadStoreOptimizer in Baf which may generate dups (or could be modified
> to); it's a peephole optimization.

I think I see what's happening. The pattern is like this, with the
middle section containing one load/dup per array element:

| store     |           |
|-----------+-----------|
| load      | dup       |
| <consume> | <consume> |
| load      | dup       |
| <consume> | <consume> |
           ...
|-----------+-----------|
| load      |           |
| <consume> | <consume> |

For an array of length 1, it's just store/load/load and this case does
get reduced to a dup. But for longer arrays, it doesn't see that the
dups can be "chained".


>
> For most VMs, store/load vs dup doesn't make any perf difference, but
> JavaCard may be different.

What actually happens is the <clinit> method gets converted into an
initialized data section containing the raw values of things to be
initialized. So the JavaCard applet converter has deduce the values
from the bytecode and it refuses to deal with load/store.