[llvm-dev] Multi-Threading Compilers

[Chris Lattner via llvm-dev]

> 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.

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200327/18dcff1e/attachment.html>