cdarnab / aparapi

Automatically exported from code.google.com/p/aparapi
0 stars 0 forks source link

"wide" opcode leads to NPE in MethodModel.foldExpressions() #42

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create a kernel with the following run() body:

int x = 0;
x += 128;

2. Execute the kernel

What is the expected output? What do you see instead?

Expected is that the kernel runs on the GPU, without side effects in this 
minimum example. What happens is the following exception, and JTP execution:

com.amd.aparapi.ClassParseException: java.lang.NullPointerException
    at com.amd.aparapi.MethodModel.init(MethodModel.java:1542)
    at com.amd.aparapi.MethodModel.<init>(MethodModel.java:1452)
    at com.amd.aparapi.ClassModel.getMethodModel(ClassModel.java:2344)
    at com.amd.aparapi.ClassModel.getEntrypoint(ClassModel.java:2377)
    at com.amd.aparapi.ClassModel.getEntrypoint(ClassModel.java:2386)
    at com.amd.aparapi.KernelRunner.execute(KernelRunner.java:1335)
    at com.amd.aparapi.Kernel.execute(Kernel.java:1682)
    at com.amd.aparapi.Kernel.execute(Kernel.java:1613)
    at com.amd.aparapi.Kernel.execute(Kernel.java:1583)
    at mypackage.MyClass.main(MyClass.java)
Caused by: java.lang.NullPointerException
    at com.amd.aparapi.MethodModel.foldExpressions(MethodModel.java:587)
    at com.amd.aparapi.MethodModel.init(MethodModel.java:1491)
    ... 11 more

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

aparapi-2012-02-15 on Linux 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:39:49 
UTC 2012 x86_64 GNU/Linux, using a somewhat unorthodox setup using Maven and 
Eclipse

Please provide any additional information below.

The bytecode provided by the compiler is the following:

0  iconst_0
1  istore_1 [x]
2  wide
3  iinc 1 128 [x]
8  return

Alternative, working kernels:

int x = 0;
x += 127;

0  iconst_0
1  istore_1 [x]
2  iinc 1 127 [x]
5  return

and

int x = 0, y = 128;
x -= y;

 0  iconst_0
 1  istore_1 [x]
 2  sipush 128
 5  istore_2 [y]
 6  iload_1 [x]
 7  iload_2 [y]
 8  isub
 9  istore_1 [x]
10  return

It seems clear to me that Aparapi is choking on the "wide" opcode. What 
Wikipedia has to say about the "wide" opcode: "execute opcode, where opcode is 
either iload, fload, aload, lload, dload, istore, fstore, astore, lstore, 
dstore, or ret, but assume the index is 16 bit; or execute iinc, where the 
index is 16 bits and the constant to increment by is a signed 16 bit short".

Original issue reported on code.google.com by sillyfre...@gmail.com on 28 Mar 2012 at 1:26

GoogleCodeExporter commented 8 years ago
Good catch. Thanks for finding this.

Looking back at the bytecode decoder we don't deal with 'wide' at all. I recall 
writing code for this, but clearly that was in some 'alternate reality'. 

I will mark this as a bug.  I should note it in the FAQ (as a restriction) 
somewhere.

It should not be too hard to fix, but I need to look into it a little more. 

Original comment by frost.g...@gmail.com on 28 Mar 2012 at 7:52

GoogleCodeExporter commented 8 years ago
Update.

I finally got a chance to look at this and have just checked in the changes to 
InstructionSet class to support this, including a fix for wide-iinc (the case 
above).  I will fold in changes for iload, fload, aload, lload, dload, istore, 
fstore, astore, lstore, dstore and ret very soon. 

Original comment by frost.g...@gmail.com on 2 Aug 2012 at 9:38

GoogleCodeExporter commented 8 years ago
I think r666 fixes this.  I added wide load and store test case to junit 
(needed > 256 local variables to create wide loads, inc and stores).

Original comment by frost.g...@gmail.com on 6 Aug 2012 at 6:10