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

Madhur Amilkanthwar via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 11 08:18:34 PST 2024


madhur13490 wrote:

> The idea makes sense, I think. I.e., bailing out before the more expensive dependence checks would be the sensible thing to do. But we do need numbers to discuss this trade-off:
> 
> * the compile time savings,
> * the number of interchanges that we miss out on, if any.
> 
> Maybe you can share those numbers for the LLVM test-suite here. Ideally, interchange triggers the same amount of times, and we save compile-time by doing the check upfront.

Thanks for reminding me. 

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`. 


> Also, it is probably better to now turn that constant `MaxMemInstrCount` into an option with a default value, so that it could be easily adjusted on the command line for testing purposes.

I have a separate change for this in which I will also expose min max depths of the loop nest using command-line options.


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


More information about the llvm-commits mailing list