IBM replaced Spyre's from-scratch sendnn compiler with Inductor extensions about 7x smaller

The 7x needs a denominator. The post describes sendnn as a separate compilation stack built entirely from scratch ^[1] and puts the size gain at roughly 7x ^[11]. If that is a size ratio, the new compiler is about 14 percent of the old one ^[15]. The summary does not say what the 7x counts, and the Inductor extensions are only the first of two stages ^[5]. For the number to transfer to another accelerator, that chip would need a second-stage compiler maintained by someone else, and its hardware would need to depart from Inductor's assumptions in as few places as Spyre's does. The post points to code-size numbers in its Evaluation section as the measure of the leverage ^[13].

Thirty-two cores with 2 MB scratchpads each add up to 64 MB of on-chip storage ^[10]. The post says the work concentrated where the dataflow design diverges from the GPU-shaped assumptions in Inductor: how Spyre moves data, manages on-chip storage and distributes work to cores ^[4]. In our view that follows from the layout. Each scratchpad is local to its core, so something has to decide what sits in which one. The post says tiling, layout assignment, work division and scratchpad allocation are decided in CustomPreSchedulingPasses ^[6].

That pass set needs to run early. Inductor's own _pre_fusion_custom_pass runs only after LoopLevelIR has been turned into SchedulerNodes, and Inductor does not support rewriting the graph at scale once those nodes exist ^[7]. Torch-spyre's passes need that kind of rewriting, so CustomPreSchedulingPasses hooks GraphLowering one step earlier, before Inductor commits to SchedulerNodes ^[9]. A monkey-patch is a fair description of a hook that does not exist yet. We'd expect every Inductor release to be a possible break until upstream formalizes one, because the patch depends on GraphLowering.codegen() keeping its name and signature.

IBM's post says Inductor "turned out to be exactly the right substrate for this work" ^[14]. The post also says: "Most of Inductor just worked." ^[12] Both statements fit the same facts. The reusable part is large, and the part that is not reusable sits at the lowest levels, where an accelerator's memory model shows up.

What the evidence shows is one team porting its own chip and reporting its own size figure. We think the general case, that Inductor can anchor compilers for non-GPU dataflow accelerators, is plausible and unproven. It firms up if the upstream hooks land and a second vendor reports a comparable port.