[llvm] [polly] [SCEV] Introduce SDiv expressions (PR #216862)

[Ramkumar Ramachandra via llvm-commits]

artagnon wrote:

> This PR is quite large and it seems to me like it can probably be broken down into parts:
> 
> 1. A patch that introduces the new expression and changes to ScalarEvolution.cpp and shows that it can be recognised. If necessary this can be tested using debug output and/or unit tests. If introducing the new expression by default would break things, the behaviour can be controlled by a flag initially.
> 2. A patch to add SCEVExpander support.
> 3. A patch to the loop vectoriser, e.g. changes to `VPSCEVExpander::expand`.

Ah, so it would not be possible to have a SCEV expression that doesn't have an expansion, as all callers of SCEVExpander that analyze IR, and get a SDiv SCEV expression that they want to expand, would essentially crash. I'm pretty neutral about the VPSCEVExpander part -- we recently "completed" it, renaming tryToExpand to expand, and we would essentially be going back to the state where VPSCEVExpander is incomplete, and rely on the IR expander (ie. vputils::getOrCreateVPValueForSCEVExpr); it's not a big deal either way, but I figured that both routes would generate some diff, and decided to preserve the completeness of VPSCEVExpander.

> At the moment it feels difficult to review. Do you have any performance measurements for benchmarks or applications where this helps?

As discussed earlier in the thread, the justification for adding a new expression to SCEV should not be because there are optimization benefits -- the trade-off we make is that it would increase the size of analyzed expressions. The justification is to optimize pointer-stride expressions, and I have a couple of drafts where I plan to use it to speculate strides. Nevertheless, we can see a diff on llvm-opt-benchmark for this change: https://github.com/dtcxzyw/llvm-opt-benchmark-nightly/pull/1028/changes.

https://github.com/llvm/llvm-project/pull/216862