[llvm-dev] Multi-Threading Compilers
Chris Lattner via llvm-dev
llvm-dev at lists.llvm.org
Fri Mar 27 09:22:34 PDT 2020
> On Mar 27, 2020, at 12:23 AM, Johannes Doerfert <johannesdoerfert at gmail.com> wrote:
> > Getting to a multithread clean optimizer is not one bug fix away -
> > this is a multiyear journey, and I would prefer not to see big changes
> > with unclear tradeoffs made in an effort to get a quick win.
> I think I missed the suggestion of "big changes with unclear tradeoffs
> made in an effort to get a quick win". So far I thought this was a
> discussion of ideas, methods to gather data, and potential pitfalls.
Making use-def chains work differently based on the dynamic type of a Value* is very problematic to me. It breaks the liskov substitution principle <https://en.wikipedia.org/wiki/Liskov_substitution_principle> and is likely to lead to widespread bugs.
> > Instead, let’s break down the problems and fix them (the right way!)
> > one at a time. For example, it seems that the thread agrees that the
> > overall design of constants are a problem: let's talk about
> > (incrementally!) moving constants to the right architecture. There
> > are good suggestions about this upthread.
> I'm not sure why you think anyone so far suggested anything to "fix it
> all" or to do it "not-incrementally". For example, I think we are
> talking about the design of constants and how it can be incrementally
> improved (for different purposes). I also think there are interesting
> suggestions upthread but I'm not sure sure there was any kind of
> agreement on "the right architecture”.
It sounds like there is agreement that whole module/llvmcontext use-def chains for constant are a bad idea. There is one specific proposal for how to fix that that is incremental and avoids the problem I mention above: use instructions to materialize them, so Constant stops deriving from Value. I would love to see this be explored as a step along the way, instead of spending time pondering how bad a break to the core APIs in the compiler would be in practice.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev