[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