“变换是程序性的” 这句话如何理解🤔

[CookieLau]

在自己尝试各种简单的transform之后发现没有一个称作”撤回(ctrl+z)“的操作，使得 sch.mod 可以回退一个 version，于是在想为什么会没有这样的一个方法：

1. 首先排除设计的时候忘了有这个需求的可能。
2. 是否是暂未实现：如果是暂未实现是因为撤回需要保存大量信息，还是某些操作没有互逆操作？
3. schedule的理念：schedule为每一次对程序优化的attempt的实例，有点一条路走到黑的意思，如果有需要撤回到上一步，可以理解为更多的场景是优化策略出现了分支（比如split 4个一组还是8个一组），而分支我们想让使用者开辟一个新的schedule来处理，而不是通过回退的方法。
4. 可能通过其他的方式实现，只是目前我还没接触到😂 看到讨论群中有人提到可以通过trace删除某个操作后再尝试，但还是不能说服自己这种通过另一个函数绕弯来实现一个“简单”的功能。

欢迎大家发票自己的看法，求轻喷

[yzh119]

实现schedule的逆操作通常比schedule本身复杂，一般没有实现（例如decompose reduction之后如果想重新组成reduction，需要做比较复杂的分析）。

[CookieLau]

感谢回答，所以相比于只支持部分schedule的逆操作而言，不提供这样的方法是一个比较直接的解决方案。

[MasterJH5574]

• 第一方面，正如 @yzh119 所说，并非所有变换的 “逆操作” 都是能够以简单的方式实现的。

• 第二方面，在第五讲自动程序优化中，我们介绍的随机变换搜索会在第一步定下搜索空间。在搜索空间确定后，我们只搜索具体的参数，而不会搜索 “是否要加一步新的变换” 或 “是否要撤销一步变换”。因此，从程序优化的角度，为每个变换实现一个 “逆操作” 并没有太多的价值，因为在我们所介绍的自动程序优化的过程中我们不需要任何的 “逆操作”。楼主提到的

  只支持部分schedule的逆操作，

  实际上设计这些变换的出发点并不是为了 “支持逆操作”，而是在优化程序的过程中我们切实地需要这些变换。比如针对循环的 split 和 fuse，在大多数情况下它们确实表现起来是 “互逆” 的，但是这只是为了性能优化设计出这两个变换所导致的结果，而非先设计某一个，再从 “支持一个逆操作” 的角度设计出另一个。

• 第三方面，我能够理解楼主可能会在交互变换的过程中有 “我这一步变换做错了，我需要变回去” 的想法和需求，确实会有这样的情况。不过我感觉最好的方式是再从头做一遍变换就好了。比如假设我第一次多做了一步 compute_at，那么第二次的时候我不做这个 compute_at 就可以了。某种角度上，这也算是楼主在最开始提到的 “从 trace 中间删除某个操作”，因为我在这里不做 compute_at 等价于我没有把这一个 compute_at 加到 trace 中去。