A Compiler for Parallel Exeuction of Numerical Python Programs on ...

identify loads that can be coalesced.Reducing the number <strong>of</strong> load instructions is only done by jit4GPU when it can findsuitable loads in the loop body to coalesce. Thus, larger loop bodies have more potential <strong>for</strong>load-coalescing. Be<strong>for</strong>e doing load-coalescing trans<strong>for</strong>mations, Jit4GPU carries out a loopunrollingpass. A larger loop body also helps the AMD IL compiler to do better instructionscheduling and register allocation. However, larger loop bodies can cause an increase inregister usage per thread that results in a lower number <strong>of</strong> threads running in parallel onthe GPU. There<strong>for</strong>e, the compiler first uses an heuristic to determine if the register usageis below a certain threshold. Loop trans<strong>for</strong>mations are only done if register usage is belowthe threshold. Estimating register usage can be time consuming but <strong>for</strong>tunately need notbe done by the JIT compiler. Register usage is estimated by un<strong>Python</strong> and it passes thein<strong>for</strong>mation to jit4GPU. If enough registers are available then a loop unroll factor <strong>of</strong> eitherfour or two is applied. The factor four was chosen because in many cases a factor <strong>of</strong> fourunroll gives good opportunities to coalesce loads into float4, the widest data type availableon GPUs. If the loop upper is not divisible by four, then an unroll by two is attemptedinstead. Inner loops are given higher priority <strong>for</strong> unrolling.Under special conditions the jit4GPU also per<strong>for</strong>ms loop fusion. Loop fusion is a looptrans<strong>for</strong>m where two loops with the same loop bounds and no dependence can be fusedinto a single loop where the loop bodies <strong>of</strong> the two loops is concatenated into a single loopbody. Thus, loop fusion produces a single larger loop from two smaller loops. However,loop fusion can only be per<strong>for</strong>med when there is no dependence between loops. Further, ifthere is some code occurring between the two loops, then loop fusion can only be appliedif the intervening code can be safely moved to a location be<strong>for</strong>e the first loop. I havenot implemented dependence analysis in jit4GPU . There<strong>for</strong>e, in general jit4GPU cannotper<strong>for</strong>m loop fusion. However, under some circumstances the dependence checking is notrequired. Let loop L 1 be a parallel loop and let L 2 be a loop contained in the body <strong>of</strong> L 1 .If L 1 is unrolled, then a copy L ′ 2 <strong>of</strong> L 2 is <strong>for</strong>med. There cannot be any dependence betweendifferent iterations <strong>of</strong> L 1 because L 1 is parallel. There<strong>for</strong>e, there cannot be any dependencebetween L 2 and L ′ 2 because L 2 and L ′ 2 are in the body <strong>of</strong> two different iterations <strong>of</strong> L 1 .There<strong>for</strong>e, the compiler can easily fuse the loops L 2 and L ′ 2.Jit4GPU per<strong>for</strong>ms all the loop trans<strong>for</strong>mations described be<strong>for</strong>e generating AMD ILcode. Jit4GPU per<strong>for</strong>ms loop unrolling and limited loop fusion followed by load-coalescingas a means to reduce the number <strong>of</strong> texture unit instructions executed. The overview <strong>of</strong> thetrans<strong>for</strong>mations per<strong>for</strong>med by jit4GPU is summarized in algorithm 6.50