[Soot-list] Unnecessary instructions in generated bytecode
Quentin Sabah
quentin.sabah at inria.fr
Tue Aug 20 06:50:53 EDT 2013
Hi,
What you observe isn't a bug, the store/load you see are correct and sound. But most compiler remove them as an optimization.
On Aug 20, 2013, at 12:19 PM, Matteo Ceccarello wrote:
> public static java.lang.String toHexString(int);
> Code:
> 0: iload_0
> 1: iconst_4
> 2: invokestatic #5 // Method toUnsignedString:(II)Ljava/lang/String;
> 5: areturn
>
> The bytecode that Soot outputs is the following:
>
> public static java.lang.String toHexString(int);
> Code:
> 0: iload_0
> 1: iconst_4
> 2: invokestatic #49 // Method toUnsignedString:(II)Ljava/lang/String;
> 5: astore_0
> 6: aload_0
> 7: areturn
The two bytecode are semantically identical. The invoke instruction returns an integer that is on the top of the stack. In the first version of the bytecode, the value on the top of the stack is immediately returned by "areturn". In the second version, the value is first popped and stored into the local variable 0 (astore_0) then pushed back on the stack (aload_0) before being returned by the last instruction.
I think there is an option to remove these "useless" store/load, probably bb.lso (see http://www.sable.mcgill.ca/soot/tutorial/phase/phase.html#SECTION000201000000000000000)
Regards.
--
Quentin Sabah, CIFRE Ph.D. student
Grenoble University
INRIA-SARDES | STMicroelectronics/AST
Montbonnot, France | Grenoble, France
mailto:quentin.sabah at inria.fr | mailto:quentin.sabah at st.com
phone: +33 476 61 52 42 | phone: +33 476 58 44 14
More information about the Soot-list
mailing list