[llvm-dev] Multi-Threading Compilers

[Nicholas Krause via llvm-dev]

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.

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