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