[llvm-dev] Multi-Threading Compilers

[Nicolai Hähnle via llvm-dev]

On Fri, Mar 27, 2020 at 5:22 PM Chris Lattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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 and is likely to lead to widespread bugs.

That's why I'm also wary of the idea of just having use lists empty
for certain types without any other special handling. However, I would
argue that if Value::use_begin() etc. contain an assertion that fails
when called on one of the value types that don't have use lists, then
the Liskov substition principle is de facto not broken. It basically
leads to a situation that is as-if Value didn't have use lists in the
first place, and only certain sub-types had use lists.

If we go down that route, maybe the inheritance hierarchy could be
reorganized in a way that makes that more obvious.

Cheers,
Nicolai


>
> > 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.