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

[Chris Lattner via llvm-dev]

> On Feb 2, 2020, at 10:35 PM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>> 
>> That's actually not how I read it. Red/green trees was *one* of the nine items you mentioned in your list and this didn't come out as the central idea in your opening paras, but let's go with this now that it's clearer to me.
> 
> Indeed, red/green trees (or DAGs) are one one of the ideas to improve
> loop optimizations, but does justify its use by itself. They happen to
> be effectively necessary for others in the list (e.g. versioning,
> profitiability heuristic by cost function, etc...) and the reason why
> I think the same cannot be done with MLIR. In hindsight, I could have
> pointed this out more in the original RFC. Note that a hierarchical
> representation was not an explicit feature in the list.
> 
> 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).

Hi Michael,

If I understand your claims, you are claiming both that red/green trees are essential for a loop optimizer, and that this essential nature “justifies” the cost of reinventing an entire compiler infrastructure is lower than the benefit of using (e.g.) MLIR to do this.  I haven’t seen evidence of either point: lots of loop optimizers exist that don’t use red/green trees.

Furthermore, my experience is that specialized IRs never get the investment in (e.g.). testing, location propagation for debugging optimized code, textual round tripping, pass management, and the multitude of other things that are required for a world class compiler implementation.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200205/f92b6f61/attachment-0001.html>