[llvm] [LoopInterchange] Constrain number of load/stores in a loop (PR #118973)

[Madhur Amilkanthwar via llvm-commits]

madhur13490 wrote:

> > When I profiled this change on LLVM Test-suite, I see 39 interchanges compared to 43 with the trunk. If I bump up the value of `MaxMemInstrCount` to 128, I see 42 interchanges. However, with 128 we see bump in the compile-time too. Please find numbers here [ ](https://llvm-compile-time-tracker.com/index.php?config=stage2-O3&stat=instructions%3Au&remote=madhur13490) the branch is `madhur13490/perf/revert_and_bound_instr_64`
> > This change tries to achieve trade-off between the number of loop interchanges and compile-time. Indeed, compile-time is directly proportional to the value of `MaxMemInstCount`.
> 
> With your results I see compile time actually increases with this patch but not decreases? For example compare the results of commit `ae719f0756` versus commit `f8c5d74865`/`bfbcc6d728`.

Ah! I think the branch is messed up due to reverts and other things in it. 

To simplify things, I have rerun the experiments yesterday. I have created two branches.
a) `perf/li_enable`  - This branch just enables LoopInterchange; no other code. On [ webpage](https://llvm-compile-time-tracker.com/?config=stage2-O3&stat=instructions%3Au&remote=madhur13490), please see the results. Geomean is +0.54%. Most interestingly, `lencod` is +2.56%

b) `perf/li-enable_bound_load_store` - In this branch, I do two things 1. Enable LoopInterchange 2. Add this patch on top of it. If you see results, geomean is just +0.28% and most interestingly in lencod we see just +1.09%. 
Thus, with this patch, I see improvements in geomean (0.54 - 0.28 = 0.26%) as well as lencod (2.56 - 1.09 = 1.47%)

FWIW, since this patch eliminates the expensive computation of dependence info in many cases and bails out early, we see an overall improvement in compile time, as expected. 

Does this clear the confusion?

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