<div dir="ltr">Hi,<div><br></div><div>Polly can only analyze (multidimensional) affine memory access. Polynomial memory access don't do well, and I see your code has some linearized arrays (that leads to polynomials).</div><div>Luckily Polly has a delinearizer that tries to recover multidimensional access from linearized ones, but the problem is that it does not always work (especially if earlier transformations "optimize" it).</div><div><br></div><div>That might be the problem here, you could look at the SCEV of the memory access if they look "nice".</div><div>I don't know how good is the delinearization in general. That is, does it survive most of LLVM transformations?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 8, 2018 at 8:37 AM, Björn Ruytenberg via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Recently I was looking at the potential of optimizing through Polly. The<br>
code that I am trying to optimize [1] adjusts a picture's colors to get<br>
an Instagram-like effect.<br>
<br>
To improve code analyzability on LLVM 3.9.0, I made the following changes:<br>
- Improve SCoP detection through -polly-process-unprofitable<br>
- Enable outer loop vectorization through -polly-vectorizer=stripmine,<br>
disabling timeouts with -polly-dependences-computeout=<wbr>0<br>
- Avoid sign extensions by replacing all 32-bit ints with longs, as<br>
Polly seems to model using 64-bit loop counters<br>
- Avoid interrupting control flow through -ffast-math and moving mallocs<br>
to the top of the code<br>
<br>
So to compile, we have:<br>
    clang -I. -O3 -g3 -Wall -Wextra -std=c99 -D_POSIX_C_SOURCE=200000L<br>
-ffast-math -mllvm -polly -mllvm -polly-dot -mllvm<br>
-polly-process-unprofitable -mllvm -polly-vectorizer=stripmine -mllvm<br>
-polly-dependences-computeout=<wbr>0 -c -o localcolorcorrection.o<br>
localcolorcorrection.c<br>
<br>
Unfortunately, LLVM 5.0.1 generates different results in analyzing the<br>
CFG compared to LLVM 3.9.0. The latter version analyzes most of the CFG<br>
[2], but 5.0.1 leaves large parts of the hot paths untouched due to "non<br>
affine access functions" [3].<br>
<br>
What I have tried:<br>
    - Moving Polly to different positions in the LLVM pass pipeline<br>
(-polly-position=early vs. -polly-position=before-<wbr>vectorizer). The<br>
latter option adds one large basic block, but otherwise doesn't seem to<br>
analyze the hot paths.<br>
    - Setting -polly-delicm-compute-known=<wbr>true and<br>
polly-delicm-overapproximate-<wbr>writes=true. This doesn't seem to have<br>
effect on the hot paths.<br>
<br>
Can anyone give me some pointers on how to fix this? Or could this be a<br>
regression in Polly?<br>
<br>
Thanks!<br>
<br>
[1] <a href="https://nautilus.bjornweb.nl/files/localcolorcorrection.c" rel="noreferrer" target="_blank">https://nautilus.bjornweb.nl/<wbr>files/localcolorcorrection.c</a><br>
[2] <a href="https://nautilus.bjornweb.nl/files/polly390-cfg.pdf" rel="noreferrer" target="_blank">https://nautilus.bjornweb.nl/<wbr>files/polly390-cfg.pdf</a><br>
[3] <a href="https://nautilus.bjornweb.nl/files/polly501-cfg.pdf" rel="noreferrer" target="_blank">https://nautilus.bjornweb.nl/<wbr>files/polly501-cfg.pdf</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Kind regards,<br>
  Björn Ruytenberg<br>
  <a href="https://bjornweb.nl" rel="noreferrer" target="_blank">https://bjornweb.nl</a><br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>
</div>