llvm dev - Feb 2020 - Writing loop transformations on the right representation is more productive

Am Mi., 5. Feb. 2020 um 18:13 Uhr schrieb Chris Lattner <clattner at
nondot.org>:
> 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.
I have spoken with multiple compiler vendors and we all could agree
that the approach of pass/transformation-local decision making is
limiting the global optimization goal the more transformations there
are.
seriously limiting the quality of global optimizations. Of those who
gave me some details, have a loop-specific data structure (although
not "red/green" trees). I don't suggest to replace anything in the
existing toolchain/pipeline, so there is no risk of regressing
anything that already works today. Every advancement will need to show
its advantages at one point, this was already the case with e.g. SSA
form.

> 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.
With writing the RFC I also try to win contributors about the
usefulness of the idea and I think it is feasible. For example, Polly
started as a research project, attracting contributors, but did not
succeed to make it a main component of LLVM because of other reasons.
I think if LLVM also want's a world class loop optimizer, some time
needs to be invested.

The discussion here is valuable for me, helping me to make my
presentation about it at EuroLLVM as relevant as possible. My current
idea is to take a complex loop nest, and compare optimizing it using
red/green DAGs and traditional pass-based optimizers.

Michael

> On Feb 5, 2020, at 8:22 PM, Michael Kruse <llvmdev at meinersbur.de>
wrote:
> 
> Am Mi., 5. Feb. 2020 um 18:13 Uhr schrieb Chris Lattner <clattner at
nondot.org>:
>> 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.
> 
> I have spoken with multiple compiler vendors and we all could agree
> that the approach of pass/transformation-local decision making is
> limiting the global optimization goal the more transformations there
> are.
> seriously limiting the quality of global optimizations. Of those who
> gave me some details, have a loop-specific data structure (although
> not "red/green" trees). I don't suggest to replace anything
in the
> existing toolchain/pipeline, so there is no risk of regressing
> anything that already works today. Every advancement will need to show
> its advantages at one point, this was already the case with e.g. SSA
> form.
Sure, to reiterate, I think that having an explicit loop nest representation is
super important.  My question was about red/green trees specifically.
>> 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.
> 
> With writing the RFC I also try to win contributors about the
> usefulness of the idea and I think it is feasible. For example, Polly
> started as a research project, attracting contributors, but did not
> succeed to make it a main component of LLVM because of other reasons.
> I think if LLVM also want's a world class loop optimizer, some time
> needs to be invested.
> 
> The discussion here is valuable for me, helping me to make my
> presentation about it at EuroLLVM as relevant as possible. My current
> idea is to take a complex loop nest, and compare optimizing it using
> red/green DAGs and traditional pass-based optimizers.
Cool.  I’d really recommend you connect with some of the loop optimization
people working on MLIR to learn more about what they are doing, because it is
directly related to this and I’d love for there to be more communication.

I’ve cc'd Nicolas Vasilache, Uday Bondhugula, and Albert Cohen as examples
that would be great to connect with.

-Chris

Am Fr., 7. Feb. 2020 um 17:03 Uhr schrieb Chris Lattner <clattner at
nondot.org
>:
> > The discussion here is valuable for me, helping me to make my
> > presentation about it at EuroLLVM as relevant as possible. My current
> > idea is to take a complex loop nest, and compare optimizing it using
> > red/green DAGs and traditional pass-based optimizers.
>
> Cool.  I’d really recommend you connect with some of the loop optimization
> people working on MLIR to learn more about what they are doing, because it
> is directly related to this and I’d love for there to be more
communication.
>
> I’ve cc'd Nicolas Vasilache, Uday Bondhugula, and Albert Cohen as
examples
> that would be great to connect with.
>
You may have already seen my discussion with Uday on the mailing list. I
would like to discuss approaches with all 3 of them, at latest at EuroLLVM
(or contact be before that, e.g. on this mailing-list thread).

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200208/e0c2a2c1/attachment.html>