一些Random thoughts，我也是mlir初学者，希望多多交流。
MLIR 只能用 g++ 编译，用 clang++ 编译会 Runtime Error。这充分地说明了一个事实：MLIR 这座庞大的大厦，是建立在脆弱的 ub (undefined behavior) 之上的。
我尝试在clang 14 15 18上编译都没有问题，这里可能有点有失偏颇了。另外，开了ubsan的话也没有ubsan报错（可能他们用了一些trick来suppress ubsan报错但感觉可能性不大）。目前mlir是隶属llvm-project，按理说不会有这种问题。
而困惑的是，这样一个输入输出系统，在运行过程中一直存在，我们随时都在反序列化 Op 来获取 operand，更新 operand 之后又序列化到通用表示上。为了完成这样的序列化、反序列化，mlir 创造了令人惊叹的冗余代码，巨大的二进制文件，令人困惑的函数定义，无处不在的 Segmentation Fault 陷阱，和未知的性能提升。
这点确实很麻，抛开op不谈，weights处理就已经很麻了，因为他是把weights直接写到mlir files里面的。debug的时候面对一长条包含weight的mlir file确实很头疼。但也能够理解这么做的需求，就是他们想让这个multi level更加能够实现。run完任何一个pass抑或是conversion，甚至只是一条简单的rewrite语句，都能有一个uniform的表示供其他pass/dialect读取和操作。
针对这条建议：
控制流、数据流分离的：控制流和数据流用不同的结构来储存，可以做分离的分析，而不是存在一个指针表里面
这个确实是非常好的建议，但我猜测可能不是mlir官方目前主要work on的目标，而是需要用户自己去实现这个事情。因为mlir我理解的还是在保证multi level ir和作为一个compiler infra这一块，这种级别的工作感觉可以算作是优化相关的操作了。如果分成两个图，那么你还要去定义一个uniform的接口来指定其他dialect、pass如何去读取，识别这两个图，如何去做映射。最后还有一大堆的lower到特定硬件上的活需要做。所以这种东西可能用户自己实现一套针对自己硬件的分离会是一个比较好的选择。而且利用现在的mlir infrastructure应该也是能够做到这一点的。
一些Random thoughts，我也是mlir初学者，希望多多交流。
我尝试在clang 14 15 18上编译都没有问题，这里可能有点有失偏颇了。另外，开了ubsan的话也没有ubsan报错（可能他们用了一些trick来suppress ubsan报错但感觉可能性不大）。目前mlir是隶属llvm-project，按理说不会有这种问题。
这点确实很麻，抛开op不谈，weights处理就已经很麻了，因为他是把weights直接写到mlir files里面的。debug的时候面对一长条包含weight的mlir file确实很头疼。但也能够理解这么做的需求，就是他们想让这个multi level更加能够实现。run完任何一个pass抑或是conversion，甚至只是一条简单的rewrite语句，都能有一个uniform的表示供其他pass/dialect读取和操作。
针对这条建议：
这个确实是非常好的建议，但我猜测可能不是mlir官方目前主要work on的目标，而是需要用户自己去实现这个事情。因为mlir我理解的还是在保证multi level ir和作为一个compiler infra这一块，这种级别的工作感觉可以算作是优化相关的操作了。如果分成两个图，那么你还要去定义一个uniform的接口来指定其他dialect、pass如何去读取，识别这两个图，如何去做映射。最后还有一大堆的lower到特定硬件上的活需要做。所以这种东西可能用户自己实现一套针对自己硬件的分离会是一个比较好的选择。而且利用现在的mlir infrastructure应该也是能够做到这一点的。