Special construction can cause Aparapi to fail parsing valid Java bytecode

[GoogleCodeExporter]

What steps will reproduce the problem?
Create a simple kernel like this:
class MyKernel extends Kernel {
  int[] a = new int[1];
  int[] b = new int[1];

  public void run() {
      a[b[0]++] = 1;
  }
}

What is the expected output? What do you see instead?
As this is valid Java (and bytecode) I expected it to be parsed.
Instead I get:
 com.amd.aparapi.ClassParseException: @16 IASTORE Detected an non-reducable operand consumer/producer mismatch
    at com.amd.aparapi.MethodModel.applyTransformations(MethodModel.java:1320)
    at com.amd.aparapi.MethodModel.foldExpressions(MethodModel.java:606)
    at com.amd.aparapi.MethodModel.init(MethodModel.java:1493)
    at com.amd.aparapi.MethodModel.<init>(MethodModel.java:1454)
    at com.amd.aparapi.ClassModel.getMethodModel(ClassModel.java:2344)
    at com.amd.aparapi.ClassModel.getEntrypoint(ClassModel.java:2377)

What version of the product are you using? On what operating system?
OSX, Eclipse

Please provide any additional information below.
The bytecode looks like this (annotated with stack state after instruction 
execution):

public void run();
  Code:
   0:   aload_0     -- this
   1:   getfield        -- a
   4:   aload_0     -- a, this
   5:   getfield        -- a, b
   8:   iconst_0        -- a, b, 0
   9:   dup2            -- a, b, 0, b, 0
   10:  iaload      -- a, b, 0, int
   11:  dup_x2      -- a, int, b, 0, int
   12:  iconst_1        -- a, int, b, 0, int, 1
   13:  iadd            -- a, int, b, 0, int+1
   14:  iastore     -- a, int
   15:  iconst_1        -- a, int, 1
   16:  iastore     --> Error, "int" is produced @11, a comes from @1
   17:  return

The parser detects that @14 is not a producer, causing it to activate the 
transform, but no suitable transform is found, hence the exception.

I do not understand the code parser design well enough to suggest a fix, but 
the above example is the smallest I can think of that looks like a real version 
in a test application.

Original issue reported on code.google.com by kenneth@hexad.dk on 9 Feb 2012 at 3:19

[GoogleCodeExporter]

Thanks Kenneth.   

I will add this to the junit test case.  

Thanks for annotating the stack this helps a lot.  

As you can probably tell if you have walked through MethodModel the dup2 and 
dup_x2 bytecodes required special handling (we create synthetic tree nodes for 
these when creating the IR) and it looks like we need to create another 'corner 
case' fix.

Obviously the code in your example can be re-coded to avoid this so I trust 
this is not blocking you.    I will dive in and take a look. 

Again thanks for this. 

Original comment by frost.g...@gmail.com on 9 Feb 2012 at 4:16

• Changed state: Accepted

[GoogleCodeExporter]

Kenneth I just got around to this and cannot recreate the bug.  

Can you tell me which compiler you were using?

Was this using eclipse or oracle's javac?

Although our bytecode is the same. Here is mine

 0:   aload_0
 1:   getfield        #2; //Field a:[I
 4:   aload_0
 5:   getfield        #3; //Field b:[I
 8:   iconst_0
 9:   dup2
 10:  iaload
 11:  dup_x2
 12:  iconst_1
 13:  iadd
 14:  iastore
 15:  iconst_1
 16:  iastore
 17:  return

And here is my generated OpenCL. 

typedef struct This_s{
   __global int *a;
   __global int *b;
   int passid;
}This;
int get_pass_id(This *this){
   return this->passid;
}
__kernel void run(
   __global int *a, 
   __global int *b, 
   int passid
){
   This thisStruct;
   This* this=&thisStruct;
   this->a = a;
   this->b = b;
   this->passid = passid;
   {
      this->a[this->b[0]++]  = 1;
      return;
   }
}

I added this test to the codegen junit tests 
(com.amd.aparapi.test.junit.codegen.ArrayTortureIssue35)

cd aparapitrunk
cd examples
cd codegen
ant 

And it does not seem fail.

Can you try running the junit tests as shown above and see if you get different 
results. 

Original comment by frost.g...@gmail.com on 20 Feb 2012 at 8:59

[GoogleCodeExporter]

Codegen is in "test" not "examples".
Here is what I get from ant:
  [junit] Test com.amd.aparapi.test.junit.codegen.AccessDoubleArray FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.AssignAndPassAsParameterSimple FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.ContinueTorture FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.Drem FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.FirstAssignInExpression FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.FirstAssignInExpression2 FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.IEEERemainderDouble FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathAbs FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathDegRad FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathFallThru FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathMax FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathMin FAILED
    [junit] Test com.amd.aparapi.test.junit.codegen.MathRemainder FAILED

But those are likely false errors because libOpenCL is not found.

My Java version is:
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11D50b)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)

My Eclipse version is:
Version: Indigo Service Release 1
Build id: 20110916-0149

And the problem was the same regardless of wether I used Eclipse or Java to 
build it.
But using the latests r268, the problem is no longer there.
It still hits (!txFormed), MethodModel.java:1292, but previously it did not 
find a match.
Now it finds the transform with "field array element post inccrement with 
nested index (local variable) ".
Not sure why that is though, but you can close this issue I think

Original comment by kenneth@hexad.dk on 21 Feb 2012 at 11:07

[GoogleCodeExporter]

That is very weird.   I do not recall modifying any of the code to fix this.

Let me leave this open for a while in case we see something similar.  I will 
create some more codegen tests and see if I can break it.

Thanks Kenneth.  

Original comment by frost.g...@gmail.com on 21 Feb 2012 at 3:20