Epilogue subtiling: store indexing fix, example, and tuple output support in run_example

[choijon5]

No description provided.

[choijon5]

@ethche I'm having trouble having the autotuner find the subtiling config. If I run is as is, I often see a slowdown. If I seed epilogue subtiling with some configs to start quick autotuning on and compare with just native quick autotuning without epilogue subtiling, I see pretty substantial speedups.

I think the speedups are a bit inflated here since the default quick autotuning baseline lands on a bad config, but I consistently see 30%+ speedups with epilogue subtiling for these kernels.
I've uploaded the benchmarking script that I've used which contains the seeding logic for epilogue subtiling. Could you take a look and see how the autotuner can be improved for finding subtiling configs?
https://gist.github.com/choijon5/5d51f13a4dfa19ee69a42a459aec4672
I run the script with "python epilogue_subtile_vs_quick_baseline.py --seed 12345 --m 8192 --n 8192 --k 8192"

[ethche]

https://gist.github.com/choijon5/5d51f13a4dfa19ee69a42a459aec4672

Thank you for letting me know. I'll look into this. Two usual issues are:

• The compile timeout is too small.
• The configs with epilogue subtiling have slightly worse accuracy and exceed autotuner tolerance.

[jansel]

Why do we need an example file here, shouldn't the autotuner find it automatically?

[choijon5]

The examples are just to illustrate to users that epilogue subtiling is supported and demonstrate cases where it can provide benefits.

[jansel]

Are we assuming all loads come before all stores? Will this always be the case? Maybe we should split loads and stores in the config or find a cleaner way to represent this?

[choijon5]

You're right. I've added tracking for the indices of stores so that we're not assuming all loads are before stores. This is a smaller change than separating loads and stores in the config.
I do think separate loads and stores is a bit more clear to users, but this is BC breaking. Happy to take this route if you think it is better in the long term.