#pragma ivdep seems not work

[Altera_Forum]

Hello, 

  I have a opencl kernel, like this:   kernel void test()  {  float array[100];    # pragma ivdep  do {  chann_data addr = read_channel_altera(chann);  int addr1 = addr.addr1;   flaot data = read_channel_altera(chann1);  array[addr1] = data;   ...   int addr2 = addr.addr2;  flaot data1 = array[addr2];   ...  }while(1)  }   After I compile the kernel, the .log file says array exist memory dependencies on store and load operation of array. So, the "#pragma ivdep" seems not work?Why?   Thank you!

[Altera_Forum]

"#pragma ivdep" is for load/store dependencies on "global" variables, not local ones. The compiler is very accurate in detecting dependencies on local variables (I haven't seen any false-positives). You seem to be using indirect addressing on your local variable, that is the reason for your load/store dependency.

[Altera_Forum]

Thanks for your reply! I am certain that addresses addr1 and addr2 never overlap, and the opencl version is 16.0. 

 But in the Intel FPGA for OpenCL Best Practices Guide, I see   "The array specified by the ivdep pragma must be a local or private memory array, or a pointer variable that points to a global, local, or private memory storage. If the specified array is a pointer, the ivdep pragma also applies to all arrays that may alias with specified pointer."  So, I think "Pragma unroll" can work on local memory? Is right?  Thank you!

[Altera_Forum]

--- Quote Start ---  "#pragma ivdep" is for load/store dependencies on "global" variables, not local ones. The compiler is very accurate in detecting dependencies on local variables (I haven't seen any false-positives). You seem to be using indirect addressing on your local variable, that is the reason for your load/store dependency.  --- Quote End ---    Thanks for your reply! I am certain that addresses addr1 and addr2 never overlap, and the opencl version is 16.0.  But in the Intel FPGA for OpenCL Best Practices Guide v17.0, I see   "The array specified by the ivdep pragma must be a local or private memory array, or a pointer variable that points to a global, local, or private memory storage. If the specified array is a pointer, the ivdep pragma also applies to all arrays that may alias with specified pointer."  So, I think "Pragma ivdep" can work on local memory in Opencl v17.0? Is right?  Thank you!

[Altera_Forum]

--- Quote Start ---  Thanks for your reply! I am certain that addresses addr1 and addr2 never overlap, and the opencl version is 16.0.  --- Quote End ---    If that is the case, then your addressing is deterministic and you MUST be able to modify your code to avoid indirect addressing. When you use indirect addressing, the compiler assumes that the addresses might overlap, resulting in a load/store dependency. The Best Practices Guide does say that the pragma will also work on local buffers, but in practice, I have never seen it working on such buffers. You can try Quartus v17.0 to see if anything has changed, but I doubt it.

[Altera_Forum]

I ran into the exact same issue a while back and after a lot of effort gave up on the ivdep approach, and I was using 17.0. Having done it myself, you sometimes can refactor your code to get around the indirect address problem but in practice it's not always possible to do so without incurring other inefficiencies that make it not worth it (e.g. excess logic, which can waste a lot of resources, and not just FFs and LUTs, but even DSPs and BRAMs) . 

 What's strange is you can do what you're attempting to do in VHDL/Verilog without a problem. In my opinion Altera/Intel should add some sort of pragma to allow you to accept or specify address collision behavior (i.e. don't care about collisions, or rd before write, etc.).

[Altera_Forum]

I strongly recommend that you guys forward your issues to Altera so that they might consider adding new attributes/pragmas, or fix the behavior of the existing# pragma ivdep.

[Altera_Forum]

--- Quote Start ---  I ran into the exact same issue a while back and after a lot of effort gave up on the ivdep approach, and I was using 17.0. Having done it myself, you sometimes can refactor your code to get around the indirect address problem but in practice it's not always possible to do so without incurring other inefficiencies that make it not worth it (e.g. excess logic, which can waste a lot of resources, and not just FFs and LUTs, but even DSPs and BRAMs) .  What's strange is you can do what you're attempting to do in VHDL/Verilog without a problem. In my opinion Altera/Intel should add some sort of pragma to allow you to accept or specify address collision behavior (i.e. don't care about collisions, or rd before write, etc.).  --- Quote End ---    Thanks for your reply!

[Altera_Forum]

--- Quote Start ---  I strongly recommend that you guys forward your issues to Altera so that they might consider adding new attributes/pragmas, or fix the behavior of the existing# pragma ivdep.  --- Quote End ---    Ok, thanks for your reply!

[Altera_Forum]

Good point HRZ. I started a support request a while back and have been in conversation with Altera about this. That said, I agree that everyone who has this issue should report it so it gets resolved.

[Altera_Forum]

Hello, 

i've got the same problem with Quartus v18.0. Pragma ivdep seems to be ignored