[llvm-dev] [Polly] Reduced code analyzability moving from LLVM 3.9.0 to 5.0.1

[Björn Ruytenberg via llvm-dev]

Hi,

Recently I was looking at the potential of optimizing through Polly. The
code that I am trying to optimize [1] adjusts a picture's colors to get
an Instagram-like effect.

To improve code analyzability on LLVM 3.9.0, I made the following changes:
- Improve SCoP detection through -polly-process-unprofitable
- Enable outer loop vectorization through -polly-vectorizer=stripmine,
disabling timeouts with -polly-dependences-computeout=0
- Avoid sign extensions by replacing all 32-bit ints with longs, as
Polly seems to model using 64-bit loop counters
- Avoid interrupting control flow through -ffast-math and moving mallocs
to the top of the code

So to compile, we have:
    clang -I. -O3 -g3 -Wall -Wextra -std=c99 -D_POSIX_C_SOURCE=200000L
-ffast-math -mllvm -polly -mllvm -polly-dot -mllvm
-polly-process-unprofitable -mllvm -polly-vectorizer=stripmine -mllvm
-polly-dependences-computeout=0 -c -o localcolorcorrection.o
localcolorcorrection.c

Unfortunately, LLVM 5.0.1 generates different results in analyzing the
CFG compared to LLVM 3.9.0. The latter version analyzes most of the CFG
[2], but 5.0.1 leaves large parts of the hot paths untouched due to "non
affine access functions" [3].

What I have tried:
    - Moving Polly to different positions in the LLVM pass pipeline
(-polly-position=early vs. -polly-position=before-vectorizer). The
latter option adds one large basic block, but otherwise doesn't seem to
analyze the hot paths.
    - Setting -polly-delicm-compute-known=true and
polly-delicm-overapproximate-writes=true. This doesn't seem to have
effect on the hot paths.

Can anyone give me some pointers on how to fix this? Or could this be a
regression in Polly?

Thanks!

[1] https://nautilus.bjornweb.nl/files/localcolorcorrection.c
[2] https://nautilus.bjornweb.nl/files/polly390-cfg.pdf
[3] https://nautilus.bjornweb.nl/files/polly501-cfg.pdf

-- 
Kind regards,
  Björn Ruytenberg
  https://bjornweb.nl