Oops, sorry for the message title, making it more descriptive now...<br><br><div class="gmail_quote">2013/2/3 Dmitry Mikushin <span dir="ltr"><<a href="mailto:dmitry@kernelgen.org" target="_blank">dmitry@kernelgen.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br><br>Yesterday, from the customer's code I observed relatively simple case, where Polly is unable to detect parallelizable outer loop. Consider two versions of Fortran routine:<br>
<br>1)<br><br>subroutine filter(H, szh, X, szx, Y, szy)<br>
<br>  implicit none<br>  integer(kind=IKIND), intent(in) :: szh, szx, szy<br>  real(kind=RKIND), intent(in) :: H(szh), X(szx)<br>  real(kind=RKIND), intent(out) :: Y(szy)<br>  integer(kind=IKIND) :: i, j, i1, i2<br>  integer, parameter :: rkind = RKIND<br>

<br>  do i = 1, szy<br>    Y(i) = 0.0_rkind<br>    do j = 1, szh<br>      Y(i) = Y(i) + X(i + j - 1) * H(j)<br>    enddo<br>  enddo<br><br>end subroutine filter<br><br>2)<br><br>subroutine filter(H, szh, X, szx, Y, szy)<br>

<br>  implicit none<br>  integer(kind=IKIND), intent(in) :: szh, szx, szy<br>  real(kind=RKIND), intent(in) :: H(szh), X(szx)<br>  real(kind=RKIND), intent(out) :: Y(szy)<br>  integer(kind=IKIND) :: i, j, i1, i2<br>  integer, parameter :: rkind = RKIND<br>

<br>  do i = 1, szx - szh
<br>    Y(i) = 0.0_rkind
<br>    i1 = i
<br>    i2 = i + szh - 1
<br>    Y(i) = Y(i) + sum(X(i1:i2) * H)
<br>  enddo<br><br>end subroutine filter<br><br>The difference between two versions is only in the way how inner reduction loop is implemented. In first case it is explicit and in second case - uses sum intrinsic, which is lowered to plain code by DragonEgg. In first case Polly successfully detects parallel outer loop, in second case - it can't.<br>

<br>Now let's see how IR codes look like upon their arrival at the beginning of Polly pass manager in KernelGen: 1.ll and 2.ll. As far as I see, the only difference between IRs is that in case of 1.ll memory location for accumulating element is updated after each fma in inner loop, while in 2.ll accumulator is updated only after the end of inner loop, producing a PHI node (or reg2mem allocas - with Polly's preopt passes). Interestingly, if you will try to optimize 1.ll further, it would yield to 2.ll too.<br>

<br>After some attempts to modify the Polly behavior, I concluded it cannot resist the presence of non-IV PHI-node. Polly attempts to produce independent basic blocks, trying to gather dependent instructions in single block and allocating scratch variables. Allocas make the situation even worse, because they are always placed into the first block of function, completely killing potential parallelism.<br>

<br>Do you see any possible workarounds in this case? Maybe alloca-s could be placed inside the inner loop to give it a chance to be parallel?<br><br>Thanks,<br>- D.<br>
</blockquote></div><br>