Torch Lowering Path Question

[maxyanghu]

Hello guys,

I have been reading code about graph lowering path, basically, the path is as follow:
Torchscript -> Translate into Torch MLIR Dialect -> Lowering into Linalg(computation ops)/Std(Basic ops)/SCF(loops/control flow) -> call IREE backend

Could someone give me some basic rationale about this path, Why directly lower down to Linalg instead of to HLO as there are optimization paths that can be reused in HLO like operation fusion, etc?

Thanks in advance,
Yang

[maxyanghu]

And I noticed mlir-hlo is an external submodule of this project, it was added in this PR:
#20

Is there going to be any dependency on mlir-hlo?

[stellaraccident]

We need to remove the mlir-hlo submodule. It is orphaned at this point. The current direction is focused on exiting via linalg because that is the level that, for the backends we are co-developing, are optimized and general. There isn't anything incompatible with folks contributing additional exits via some HLO dialect (mhlo, tosa, etc), but that would probably be more for the integration value with particular backends vs an optimization argument. From a practical standpoint, neither of those dialects right now (tosa or mhlo) has the generality to express npcomp programs -- specifically, they are constrained to tensor operations, have incomplete support for symbolic shapes, lack some structures needed to model state/control flow/etc. We wanted a starting point that let us embrace that generality and see if we could use it as a lever to put requirements on those systems for future growth. In the industry, I've more seen the opposite being done: restricting user features based on arbitrary restrictions of backend compilers. At this point, too, it isn't really safe to assume that mhlo inherently gives you more optimizations than bypassing it, but that varies by backend. There was a talk in a recent MLIR ODM ("from MHLO to linalg") where some folks walked through more rationale and examples. In that context, the move was done because it opened more opportunities for optimizations.

…

On Wed, Jul 28, 2021, 5:52 AM Maxi ***@***.***> wrote: And I noticed mlir-hlo is an external submodule of this project, it was added in this PR: #20 <#20> Is there going to be any dependency on mlir-hlo? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYVAFZ5HINAOKQNXWJXNDTZ74STANCNFSM5BED2LJA> .

[silvasean]

I have a long overdue presentation on the rationale for this backend layer / lowering path... give me some time.

[maxyanghu]

Thanks, stellar. for the detailed explanation... I am taking some time to watch the talk you mentioned.