[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