[llvm-dev] Multi-Threading Compilers

Sat Mar 28 13:35:50 PDT 2020

On Sat, Mar 28, 2020 at 12:41 PM Nicholas Krause <xerofoify at gmail.com>
wrote:

>
>
> On 3/28/20 5:39 AM, Nicolai Hähnle via llvm-dev wrote:
> > On Fri, Mar 27, 2020 at 9:55 PM David Blaikie <dblaikie at gmail.com>
> wrote:
> >> 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.
> > It's not a break of the Liskov substitution principle, though. For
> > example: In the proposal, you can iterate over uses of an Instruction,
> > and you can iterate over uses of all sub-types of an Instruction. You
> > can't iterate over Constant, but then Constant isn't a sub-type of
> > Instruction.
> >
> > It's a bit of an academic point. What you're really trying to say is
> > that with this particular version of the proposal, it is not
> > **statically** checked at compile-time whether a Value has iterable
> > use lists, and that makes it easier to write incorrect code
> > accidentally. Yes, that's a weakness, and precisely the reason why I
> > suggested that we may want to re-organize the inheritance hierarchy of
> > Values.
> >
> > Cheers,
> > Nicolai
> >
>   Nicolai,
> Please stop removing me from the CC I asked in a previous email to be
> CCed so I can follow
> the discussion.
>

I don't think anyone's /removing/ you, we're just replying to the relevant
emails/subthreads which you aren't already on/won't get on this way,
generally. Might be the best thing to in some way flag this thread in your
mail client rather than asking others to handle email threads differently
for your use case.

- Dave

>
> Thanks,
> Nick
> >>> 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/20200328/49a406bc/attachment-0001.html>