Results 1 to 10 of 10

Thread: #pragma ivdep seems not work

  1. #1
    Join Date
    Apr 2017
    Posts
    44
    Rep Power
    1

    Default #pragma ivdep seems not work

    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!
    Last edited by exciting678; December 6th, 2017 at 05:05 PM.

  2. #2
    Join Date
    Jan 2017
    Posts
    443
    Rep Power
    1

    Default Re: #pragma ivdep seems not work

    "#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.

  3. #3
    Join Date
    Apr 2017
    Posts
    44
    Rep Power
    1

    Default Re: #pragma ivdep seems not work

    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!

  4. #4
    Join Date
    Apr 2017
    Posts
    44
    Rep Power
    1

    Default Re: #pragma ivdep seems not work

    Quote Originally Posted by HRZ View Post
    "#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.
    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!
    Last edited by exciting678; December 6th, 2017 at 05:46 PM.

  5. #5
    Join Date
    Jan 2017
    Posts
    443
    Rep Power
    1

    Default Re: #pragma ivdep seems not work

    Quote Originally Posted by exciting678 View Post
    Thanks for your reply! I am certain that addresses addr1 and addr2 never overlap, and the opencl version is 16.0.
    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.

  6. #6
    Join Date
    Nov 2014
    Posts
    18
    Rep Power
    1

    Default Re: #pragma ivdep seems not work

    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.).
    Last edited by dark_visage; December 7th, 2017 at 08:00 AM.

  7. #7
    Join Date
    Jan 2017
    Posts
    443
    Rep Power
    1

    Default Re: #pragma ivdep seems not work

    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.

  8. #8
    Join Date
    Apr 2017
    Posts
    44
    Rep Power
    1

    Default Re: #pragma ivdep seems not work

    Quote Originally Posted by dark_visage View Post
    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.).
    Thanks for your reply!

  9. #9
    Join Date
    Apr 2017
    Posts
    44
    Rep Power
    1

    Default Re: #pragma ivdep seems not work

    Quote Originally Posted by HRZ View Post
    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.
    Ok, thanks for your reply!

  10. #10
    Join Date
    Nov 2014
    Posts
    18
    Rep Power
    1

    Default Re: #pragma ivdep seems not work

    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.

Similar Threads

  1. Is there a pragma to prevent loop pipeline?
    By Lancerchiang in forum OpenCL
    Replies: 3
    Last Post: November 23rd, 2017, 08:32 PM
  2. Replies: 3
    Last Post: October 24th, 2017, 07:32 PM
  3. #pragma pack doesn't work correctly
    By ITH in forum General Software Forum
    Replies: 1
    Last Post: June 24th, 2014, 06:47 AM
  4. pragma optimize
    By efourmon in forum General Software Forum
    Replies: 0
    Last Post: September 8th, 2010, 07:45 AM
  5. Equivalent of #pragma message in verilog
    By kito in forum Quartus II and EDA Tools Discussion
    Replies: 0
    Last Post: May 5th, 2010, 03:54 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •