Sorry I took a long time to reply as it took me some time to get some understanding of the code even to ask some specific questions (I have a test case in which LSR does not kick in and wanted to understand the code to figure out why it was not kicking in).
Here are some specific questions I have:
1) It appears that LSR works only for the inner-most loop. Is this correct?
Yes, that is correct.
Can you tell me why this is so?
The rationale was that supporting outer-loops complicates the whole implementation whereas most of the performance gain are within the inner-most loop. Therefore we decided it was not worth the complexity.
I believe SCEV works for nested loops, right?
I believe that is correct.
2) Can LSR work for those LSR uses in a nested loop whose associated formulae themselves do not span multiple loops, ie. the formulae do not have references to loops other that the one that is being processed currently?
In theory, yes.
Of course, we first need to get rid of the checks which currently restrict LSR only to the innermost loop
3) Why do we compute “chains” upfront in the CollectChains() function and then generate all the LSR uses with the associated formulae, prune the formulae, compute the solution and then finally refer to the chains computed in the first step to implement the solution?
That’s a very good question!
I believe this is a historical accident before the time we started to prune the search space. We could probably be smarter here.
Can the chains somehow drive the LSR use and formulae generation process to restrict the latter to only those that are “interesting” for the chains computed?
4) I may have mis-understood the code, but it seems that the function SolveRecurse() succeeds in computing a solution only if every LSR use has at least one formula associated with it. For example, if all the formulae associated with an LSR use get filtered away, it appears that the SolveRecurse() function would not compute a solution and instead say “No Satisfactory Solution”. In my example, an LSR use has all the formulae associated with it filtered away as they are all “loser” formulae and I do not get a solution from the SolveRecurse() function. Is it correct for the SolveRecurse() function to ignore LSR uses without any associated formulae and come up with a solution that involves the other LSR uses?
That is correct.
Maybe, this will create an inefficient solution, but would it create an incorrect solution?
I believe the rewriter logic is not ready for that, so that would be incorrect, but if we solve that would just be inefficient.
Right now, SolveRecurse() seems to take an all-or-nothing approach. My apologies if I have completely mis-understood the concepts of LSR use and formulae but I am just trying to understand all this from the code and that is proving very difficult to do
5) Given the current implementation in SolveRecurse() function, why not check if there are LSR uses with no associated formulae and not even execute the SolveRecurse() function? This would avoid some compile time overhead, wouldn’t? SolveRecurse() does not need to be called if an LSR use has an empty formulae set associated with it because even if you called it you would not get a solution from it, right?
That’s correct too.
Though I would have expected we reject those cases earlier.