Blocking for partial directions
In the current implementation, it was only possible to block for all coordinates. However, for some problems it might make sense to only block one specific direction. This can now be achieved by setting unwanted coordinates to zero.
Merge request reports
Activity
1307 1315 stop = sp.Min(inner_loop.stop, block_ctr + block_size[coord]) 1308 1316 inner_loop.start = block_ctr 1309 1317 inner_loop.stop = stop 1310 return len(coordinates) 1318 return coordinates_taken_into_account So this function returns a magic number that will be consumed by OpenMP's
collapseand this will work the right way whatever block size you're specifying here? Shouldn't OpenMP collapse all looks that enclose those blocking loops (not how many loops do not use blocking) and avoid that collapse is applied for coordinates that use blocking. Then, this version wouldn't be correct. Anyways, should OpenMP get this information in a way that is less magical (e.g. directly from blocking dimension).
So I think collapse should be applied to the number of blocking loops we have produced because they share the same iteration space as the original loops right? I think this was the way of thinking which got into this function originally.
I think it makes sense to return the number of blocked coordinates then and I am not sure if it is a good idea to just directly extract that information form the blocking tuple. At the moment coordinates_taken_into_account is only increased if a new outer_loop is really produced. If we just extract the information from the tuple it might be more error prone, right?
I'm not really familliar with this code. The changes look ok, though appart from the interference of the return value with OpenMP.
Edited by Stephan Seitz404 404 405 405 class LoopOverCoordinate(Node): 406 406 LOOP_COUNTER_NAME_PREFIX = "ctr" 407 BlOCK_LOOP_COUNTER_NAME_PREFIX = "_blockctr" 407 BLOCK_LOOP_COUNTER_NAME_PREFIX = "_blockctr" mentioned in commit facd3ab4
