[PATCH] D46735: [Test-Suite] Added Box Blur And Sobel Edge Detection

[Johannes Doerfert via Phabricator via llvm-commits]

jdoerfert added a comment.

In https://reviews.llvm.org/D46735#1096084, @Meinersbur wrote:

> Some context: Pankaj is a GSoC student on a project to add more Polly-optimizable benchmarks. Currently, only SingleSource/Benchmarks/Polybench is really optimizable, most other benchmarks contain some kind of pre-optimization that makes it difficult for Polly to preserve semantics, even if the algorithm itself is 100% optimizable.


First, let me keep the record straight:

- Only SingleSource/Benchmarks/Polybench profits from the (mostly tiling) transformations applied by Polly.
- There are various reasons why other benchmarks are "not optimizable" by Polly but only a fraction is caused by manual "pre-optimizations" (except the input language choice obviously).
- Adding simple "Polly-optimizable" benchmarks is all good and well (as it makes for nicer evaluation sections in future papers...), but I would argue it is much more interesting to investigate if the existing benchmarks could be optimized and why they currently are not.

Regarding these (and other new) benchmarks:

- Please describe why/how the codes differ from existing ones we have (e.g., Halide/blur). Polybench already contains various kernels including many almost identical ones.
- Please describe why/how the magic constants (aka sizes) are chosen. "#define windows 10" is not necessarily helpful.
- I fail to see how Polly is going to optimize this code (in a way that is general enough for real codes). So my question is: Did you choose a linked data structure on purpose or do you actually want to have a multi-dimensional array?

Finally, regarding the actuall code, I would run clang format and remove these blocks of empty lines.


Repository:
  rT test-suite

https://reviews.llvm.org/D46735