[quote="junrushao1994, post:23, topic:1721, full:true"] It’s true. Handcrafting doesn’t scale when # of ASICs increases. [/quote]
Hmm I dont think TVM really has a bigger problem of hand-crafting (read my comment to the next quote), also I think every ASIC developer would have to commit to "at least" defining TVM scheduling rules. Getting that for free would obviously be nice but I dont think its realistic. That scaling in # ASICs would be completely transparent to development of the TVM infrastructure. There is some flexibility in TVM's scheduling rules. I mean given a certain layer-type with (or without) possible fusions, you can have more than one scheduling rule. You would have a higher-level scheduling rule decision making module (which is purely SW) to actually pick which of the scheduling rules to use. Yes the scheduling rules are then hand-crafted, but most likely somewhat templated so that at least to some degree you can generate diverse "flavours" (imagine the block sizes and ordering of loops) of the routine. [quote="yzhliu, post:22, topic:1721, full:true"] polyhedral optimization (or at least the ability to easily apply polyhedral-like analysis) might be attractive for ASICs though, it could help to build a smarter tensorizer. [/quote] I am no expert in polyhedral scheduling, but that sounds like very complex problem to solve (at least fully automated). Polyhedral would technically not require these templates, but would require the scheduling algorithm to be conforming to the capabilities to the ASIC datapaths, address generation patterns, accelerator system resources (possible scratchpad usage), etc. This for any kind of operator fusion. Here I would guess that some templated schedules or constraints would again be handcrafted. The set of loop optimizations that TVM natively supports is a subset of all possible with polyhedral, so it would be interesting to know which are not available (not even through a mix of TVM scheduling primitives). The only one I can think about is loop skewing (to generate a SW pipeline), but even then I have a mindsketch of how it could still be realizable without any extension of the TVM primitives. **If someone is a poly expert and totally against what I say __ please __ contribute to thread or contact me!!!!** @tqchen There is one thing which I think TVM could do better and would probably fit into the MLIR vision, and that is allowing the NNVM/Relay fusion rules of nodes to be an input from ASIC backend developers. Obviously one path is to turn-off all fusion and then implement "glue fusion" routines which are more target dependent (each ASIC developer would have to do this), but I am not sure if it would break some of the reusability of TVM code (i.e. example TVM routines to visit nodes in a graph or something like that). I guess another path would be to overwrite some layer type definitions (ex: if I want to fuse conv and pool, then define pool as element-wise operation, again every ASIC developer would have to do this) but then again I have no idea what extra problems that brings down the road. --- [Visit Topic](https://discuss.tvm.ai/t/google-lasted-work-mlir-primer/1721/24) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/90e4d7f53faffe79ae6cb0152eb1741ee83d94eab3bfeb5ea3fff85fe93f3e99). Tianqi Chen, UW, Seattle, WA, 98105, United States http://tracking.discuss.tvm.ai/tracking/unsubscribe?msgid=fxShickInnadC_rW-4FoCQ2
