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

[Björn Ruytenberg via llvm-dev]

Hi Johannes,

Perfect, thanks! The CFG now looks very similar to what I got on LLVM
3.9.0 ([1] vs [2]).

Any idea why setting -simplifycfg-sink-common=false is necessary?
Similar to LLVM 5.0.1, the default for 3.9.0 is true [3], and setting it
to false wasn't necessary in the latter version.

[1]
https://nautilus.bjornweb.nl/files/polly501-cfg-simplifycfg-sink-common.pdf
[2] https://nautilus.bjornweb.nl/files/polly390-cfg.pdf
[3]
https://github.com/llvm-mirror/llvm/blob/release_39/lib/Transforms/Utils/SimplifyCFG.cpp#L71

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


On 09/03/2018 09:18, Johannes Doerfert wrote:
> Hi Björn,
> 
> try to add this:
> 
>   -mllvm -simplifycfg-sink-common=false
> 
> Cheers,
>   Johannes
> 
> On 03/08, Björn Ruytenberg via llvm-dev wrote:
>> 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
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>