[llvm-dev] Writing loop transformations on the right representation is more productive

[Michael Kruse via llvm-dev]

Am Sa., 8. Feb. 2020 um 12:22 Uhr schrieb Uday Kumar Reddy Bondhugula
<uday at polymagelabs.com>:
>> To convince me that MLIR is the better IR for loop optimizations,
>> might show that each of the features enabled by cheap subtree reuse
>> can also be done sufficiently efficient and easily on MLIR (or that a
>> feature is not what would actually would want).
>
>
> I suspect that you are looking at this as "MLIR vs your proposal", but the point I've been trying to make is to compare "your proposal on MLIR" vs "your proposal on LLVM", i.e., you may want to evaluate the cost/benefit of hosting your approach on MLIR vis-a-vis LLVM while accounting for the fact that you'll need the conversion for LLVM to MLIR and back for the relevant IR units with the former. On this note, in my opinion, MLIR doesn't have a unified/clear strategy for loop optimization yet (even op representation wise); there are different ops/representations that are being pedalled by different folks, and some I believe are redundant or are simply duplicating infrastructure in less powerful ways. I'm saying this because if you choose MLIR to host your stuff, you'll have choices to make on which forms to use.

I was indeed interpreting your arguments as "MLIR vs your proposal".
Is mentioned in the original RFC, I would also like to make "proposal
on MLIR" work (mostly for flang), but "proposal on LLVM" for new seems
to offer the greater benefit. MLIR has the advantage that it can carry
more semantics from the front-end that can be used (multi-dimensional
array subscripts, already parallel loops, ...).



>> >> (which I firmly disagree with being close to MLIR's in-memory representation), not the textual format.
>> >
>> > "close" isn't the right word here, "closer" is! Would you agree that the representation you are proposing is closer to MLIR's representation (both its in-memory and its textual representation) than to LLVM's or is this proximity not really relevant for the purposes of your proposal? I think it's important to know which among the two is the more important question.
>>
>> I think MLIR is an evolution of LLVM-IR and Swift-IR, built around
>> similar principles such as SSA and Control-Flow Graphs (I understand
>> that in addition to CFGs, MLIR also enables structured control flow
>> idioms). SSA is a distinguishing feature: It allows to quickly
>> traversing def/uses (where compilers without it need a data-flow
>> analyses), but make subtree reuse hard.
>>
>> Does this answer your question?
>
>
> Not directly, but I think I have more information now. You are probably saying it's nearly as easy/difficult to host your approach on LLVM IR as it is on MLIR.

Yes.