[llvm-dev] Multi-Threading Compilers

[David Blaikie via llvm-dev]

On Fri, Mar 27, 2020 at 1:53 PM Nicolai Hähnle via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

But it doesn't - it means you write some generic code, test it with some
cases & looks like it generalizes to other cases (you don't want to/can't
test generic code with all possible generic arguments - that's why
substitutability is important) then the code breaks when it hits a constant
Value because it doesn't conform to the contract.


> 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200327/ebdb168a/attachment.html>