[Soot-list] question about Soot optimization

[Tobias Gutzmann]

Hi,

I don't think that's entirely true, Eric. Such an optimization should be 
allowed as long as "b" is not "volatile"
See table 17.4 at the JVM spec: 
http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4
It's not exactly the same, but a similar situation.

/Tobias

On 2012-04-25 10:38, Eric Bodden wrote:
> Hi Mu.
>
> The optimization you propose is not sound in multi-threaded programs.
> The field's value could have been modified between both assignments,
> which would make the second assignment necessary.
> My guess is that, since usually Soot has no knowledge about whether
> your program is multi-threaded or not, or which parts of it may be, it
> assumes the worst and hence does not apply the optimization.
>
> Eric
>
> On 25 April 2012 01:29, Mu Zhang<muzhang82 at gmail.com>  wrote:
>> Hi,
>>
>> I have a question about Soot optimization. I'm writing a program to
>> instrument Java bytecode and using Soot to remove redundant code. However, I
>> found Soot was not able to optimize the instrumented code in some cases.
>> Here is an example and the redundant instructions are in black:
>>
>> public int cryptWrapper(int, tester.BoolWrapper, tester.BoolWrapper,
>> tester.BoolWrapper)
>>      {
>>          tester.B r0;
>>          int i0, i1, $i2;
>>          tester.BoolWrapper r1, r2, r3;
>>          boolean z0, z1, z3, z4;
>>
>>          r0 := @this: tester.B;
>>          i0 := @parameter0: int;
>>          r1 := @parameter1: tester.BoolWrapper;
>>          r2 := @parameter2: tester.BoolWrapper;
>>          r3 := @parameter3: tester.BoolWrapper;
>>          z0 = r2.<tester.BoolWrapper: boolean b>;
>>          z1 = r1.<tester.BoolWrapper: boolean b>;
>>          z3 = r3.<tester.BoolWrapper: boolean b>;
>>          $i2 = r0.<tester.B: int key>;
>>          i1 = i0 ^ $i2;
>>          z4 = z1 | 0;
>>          r2.<tester.BoolWrapper: boolean b>  = z0;
>>          r1.<tester.BoolWrapper: boolean b>  = z1;
>>          r3.<tester.BoolWrapper: boolean b>  = z4;
>>          return i1;
>>      }
>>
>> Basically, z0 is assigned with r2.b and later is assigned to r2.b without
>> any modification in between. I was wondering if it is because Soot considers
>> r2.b to be an object field with side-effects and thus doesn't optimize it.
>> If that is true, I'm curious to know how Soot determine whether a local has
>> side-effects or not. Does it simply consider all objects have side-effects?
>> Also, is there a way to trick Soot and bypass the check, so that it can
>> optimize some certain instructions that may have side-effects?
>>
>> Thanks,
>>
>> Mu
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>
>