[PATCH] D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3)

Thu Jun 17 02:46:31 PDT 2021

nikic added a comment.

In D102615#2824000 <https://reviews.llvm.org/D102615#2824000>, @mkazantsev wrote:

> Currently scheming a prototype to see if it works. My speculation is InstSimplify might be enough for my motivating example. However, this will require massive refactoring of InstSimplify itself (some of its static functions will need to be made publicly available). It's a lot of work just to duplicate a part of what SCEV does out of box.

This is surprising to me -- why does this require changes to InstSimplify? I would have expected that using it is simpler, not more complicated, as the SCEV use effectively requires you to reimplement the whole createSCEV() logic (which this patch only does to a small degree).

> @nikic
>
>> The case here is different: This optimization only has a nominal relation to loops.
>
> I disagree. If we think something is a loop, we will run all our loop passes (including IndVars and LSR) on it. However, if loop deletion proves it's not a loop, we may save time on costly opts in other places. But again, whether this will or will not happen frequently, or whether the overall impact is positive, is a very speculative ground on which neither of us have (or may have) enough evidence.

I think my point may have been lost here: Yes, there is a loop structure here, but you don't make use of it, because you're specifically trying to prove that it is not actually a loop. You are looking at only one iteration, in which case it is straight-line code. Any loop-based reasoning SCEV does is actively unwanted here.

>> There are no add recurrences involved, there is no "scalar evolution" going on -- rather, SCEV is being used as a generic symbolic reasoning framework, which is not a use-case it is intended or optimized for.
>
> And LLVM is not "low level" and not a "virtual machine", right? :) It's just a wordplay.
> Just because the initial motivation for SCEV was loop passes (maybe IndVars), I don't see any reasons why it cannot be used as generic symbolic framework. It has all power of it, it has tons of simplification that has nothing to do with loops, its implication engine does a lot to prove non-recurrent things. Today we even use it for pointers. I see no reason why we should stick to something that was relevant in the past and hold away the further expansion of its usage.

Okay, if we consider SCEV as a generic symbolic reasoning framework that is intended for non-loop analysis, then the usage here makes more sense to me. This isn't how I've been thinking about SCEV.

As said before, I'm okay with this going in as-is if you think it's the right approach -- I think I made this a bigger issue than it really deserved, because it ended up being a kind of proxy issue for the general problem of improvements to SCEV or new uses of SCEV leading to inevitable compile-time regressions. I don't actually think the regression in this patch is particularly problematic, my concern is more cumulative in nature, as this is not the first (or second, or third) time this happened... There's always talk that we should make SCEV faster, but there has been little actual movement in that direction.

(If we can solve motivating cases via SCCP or some improvements / phase ordering changes to it, that would still be my first preference, as I think that pass is perfectly suited to this problem from an algorithmic perspective.)

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102615/new/

https://reviews.llvm.org/D102615