Is there a pragma to prevent loop pipeline?

Altera_Forum · ‎11-24-2017

Hi,

Is there a pragma in altera opencl which can prevent a loop being pipelined? I have some outer loop which do not have to be pipelined but inferred to be pipelined which (I assume) caused some excessive resource usage.

Thanks!

Altera_Forum · ‎11-24-2017

I am afraid there is no such option. Performance-wise, you wouldn't want to do this either. Pipelining outer loops will use excessive area only if the II is larger than one, forcing the compiler to increase the depth of the buffer to allow correct pipelining. If the II is one, the area overhead will be minimal, and the performance improvement will be substantial.

Altera_Forum · ‎11-24-2017

Thanks for your reply! I have a structure like this


for(...) {
    
    operation: load global memory to local buffer X
 
    //this loop should be pipelined and it's pretty deep
    for(....) {
        
      operation: perform computations which do not use X
    }
    
    operation: use X to do another computation based on the result from the inner loop
}

I don't see how the outer loop can be pipelined. Because The next iteration's loading to the local buffer X cannot start untill the current iteration finishes. But the compiler says the outer loop has II of 2

Altera_Forum · ‎11-24-2017

Unless you are overwriting some indexes in the local buffer, or you are reusing some index from the buffer which has been updated in a previous iteration (resulting in a load/store dependency), I do not see any problem with the outer loop being pipelined here. the compiler follows a very conservative approach when it comes to detecting dependencies; rest assured that there is no way the compiler might miss an actual dependency in your code.

Note that sometimes, the compiler says the II of the outer loop is 2 because it includes a terminating a sub-loop, but further in the report it says the outer loop executes serially over the inner loop due to some dependency, which basically means the outer loop is NOT pipelined. This is one of the few cases where the compiler will actually waste some area on the outer loop to support a minimum II of 2, while in practice the loop will be always running sequentially. I think this behavior has been improved/fixed in v17.0+.