tvm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aca88 via TVM Discuss <>
Subject [TVM Discuss] [Development] Google lasted work: MLIR Primer
Date Tue, 09 Apr 2019 09:42:12 GMT

[quote="junrushao1994, post:23, topic:1721, full:true"]
It’s true. Handcrafting doesn’t scale when # of ASICs increases.

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.

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!!!!**

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]( to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](

Tianqi Chen, UW, Seattle, WA, 98105, United States
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message