Thank you all for your replies.
[quote="tkonolige, post:2, topic:9893"] It’s hard to figure out where to register the fixed inputs. For sparse its done in the pass that converts dense matrices to sparse (which means you don’t get fixed inputs if you model is already sparse). [/quote] Seems that autoscheduler already supports tuning a whole model from dense to sparse. Initially I was considering tuning a single operator, and I'd like to hold on to it for now and come back later with more background. Agreed that we should have a better, unified mechanism for sparse inputs. [quote="areusch, post:4, topic:9893"] I’m okay with bringing something back so long as we have a way to either 1. handle layout transformations to `ref_input` 2. determine when layout transformations have occurred and not do output checking or warn/fail autotuning when output checking can’t be done [/quote] I think the real problem is that autotvm does not officially support layout transformation, thus we all go implicitly, and then the correctness check fails. Following R1 might suggests a larger-scale design change. On the other hand, previously `ref_input` can be enabled without setting the `check_correctness` option, and it just works implicitly (the attribute is [always](https://github.com/apache/tvm/pull/7250/files#diff-f8cbe8a70063c3692732fa42db6f11779f92eb2afeb5576b68b7ede8064a8222L315) submitted to the executor). IMO output checking is not a requirement for this piece of code, it can be safely decoupled, and easily accomplished with external developer efforts. --- [Visit Topic](https://discuss.tvm.apache.org/t/autotvm-interface-for-fixed-input-data/9893/5) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/4c6d920e84cc1a7c9d253aa3d6d05e3f79088bd0cf36217372299c368006f502).
